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THE UNIVERSITY 

Arizona State University is part of a tri-university 
system governed by the Arizona Board of Regents. ASU is a 
multicampus university with ASU Main located in the city of 
Tempe, ASU West in northwest Phoenix, a major educational 
center in downtown Phoenix, and other instructional, 
research, and public service sites throughout Maricopa 
County, ASU's enrollment for the Fall 1992 semester was 
43,635. ASU offers almost 300 degree programs through nine 
colleges and one professional school. 

THE ENROLLMENT 

Like many schools, ASU has been faced with a declining 
applicant pool of graduating high school seniors and has 
been considering developing a system that would help to 
identify, contact, track and enroll prospective students. 
As early as Fall 1985, a Joint Application Design (JAD) 
session was held to identify requirements and develop a 
preliminary design for a marketing/recruiting system for the 
Undergraduate Admissions office. Periodically, the JAD 
document would be taken down from the shelf, dusted off and 
reviewed - but with programming resources being devoted to 
maintaining existing mainframe systems, the 
marketing/recruiting project never materialized. 

The impetus for taking action came with a decline in 
new out-of-state freshman enrollment for the Fall 1990 and 
1991 semesters. State funding for ASU is based on an 
amount calculated on full-time equivalent enrollment 
figures. Since out-of-state students pay a heftier portion 
of the cost of their education than Arizona residents, a 
drop in the number of out-of-state students can 
significantly impact funding for the university. To 
address this decline in enrollment and to maintain a diverse 
student population, the administration decided to 
aggressively pursue the Undergraduate Admissions office's 
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request for a marketing/recruiting system. Since results 
were desired for the Fall 1992 semester, decisions needed to 
be made quickly. 

THE CHALLENGE 

On Friday, December 13, 1991, the ASU Provost approved 
the acquisition of a telecounseling/recruiting software 
system. In order to have a positive impact on Fall 1992 
enrollment, an installation target date of January 24, 1992 
was established. 

The Undergraduate Admissions office was selected as the 
installation site and the Director of Undergraduate 
Admissions was identified as the overall project leader. 
Specific responsibilities of the Undergraduate Admissions 
office included entering into a contract with an outside 
vendor for a telecounseling/recruiting system, identifying, 
implementing and coordinating marketing and recruitment 
strategies, and overall accountability of the success of the 
project. 

The Student Information Systems (SIS) office, a^ 
distributed computing support group within the division of 
Student Affairs, was given the responsibility of purchasing, 
testing, and installing all of the required hardware and 
software and coordinating the voice and data communications 
requirements - within the twenty-six working days before the 
target installation date. 

THE VENDOR AND THE SYSTEM 

Noel/Levitz Centers for Institutional Effectiveness and 
Innovation Inc., an Iowa based educational consulting firm, 
was selected as the vendor. Noel/Levitz markets a 
telecounseling system called DIALOGUE . DIALOGUE is a 
telephone communications system that enables personalized 
communications and promotes relationship building with 
prospective students. Designed to run on a local area 
network (LAN) using the Novell 3.11 operating system, the 
system will initiate, maintain, track and report on 
prospecting activities throughout the full recruiting cycle. 
The system was developed using Clarion 2 . 1 as the RDBMS. The 
installation is customized by Noel/Levitz to address the 
unique needs of each university. 

THE LAN 

Selection of the Undergraduate Admissions office as the 
site for the installation of the system meant acquiring and 
installing a new LAN. Existing workspace was converted to 
accommodate the new LAN. At ASU, the LAN is a subnet 
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connected to the university 1 s ethernet backbone. 
Workstations are connected to the backbone through ethernet 
twisted pair connections. This allows access to both the 
LAN and the university 1 s VM and MVS mainframe computers. 

A dial-in facility, using CloseUp Remote 3,0 
communications software, is used by Noel/Levitz personnel in 
Iowa to identify and resolve problems with the system. The 
dial-in facility is also available to SIS support staff to 
identify and resolve problems with the LAN. 

The fileserver is an Everex 486/33 20.8 MIPS server 
with 16MB RAM and two duplexed 676MB SCSI drives. The. 
workstations are HAL-2001 386/25 CPUs with 4MB RAM and 4 0MB 
hard disks. Each workstation has a VGA color monitor and 
one 1.44MB 3.5 floppy drive. One workstation was 
designated as the telecounseling supervisor's workstation. 
The supervisor's workstation has an 80MB hard disk, 8MB RAM, 
a 2400 baud internal modem, and a 2GB tape backup unit 
attached. 

A total of twenty workstations were purchased, 
replacing twenty 3270 terminals in the Undergraduate 
Admissions office. Eight existing workstations were 
upgraded to permit network access. Twenty-six of the 
workstations are located in the Undergraduate Admissions 
office. Two of the new workstations were located in the 
Student Financial Assistance office and the Residential Life 
office, respectively, and configured to permit access to the 
new system. 

As part of disaster recovery planning for the 
Admissions' fileserver, upgrades wer^ acquired for the 
existing LAN in the SIS office. The SIS server functions 
cis a backup to the Admissions' server. One benefit of 
having ethernet twisted pair connections is the SIS server 
does not have to be physically relocated to the 
Undergraduate Admissions office in the event of a system 
failure. A batch file on each of the workstations will re- 
direct access to the SIS server in the event of a system 
failure in Admissions. 

For a summary of the hardware and software installed, 
reference Attachments A and B. 

THE DATA 

The data the telecounseling/recruiting system uses 
comes from several sources. One source is external testing 
agencies such as ACT and SAT. When a student takes the ACT 
and/or SAT test, they are given the opportunity to have 
their scores and other demographic data sent to post- 
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secondary schools of their choice. ASU receives the 
prospective student information on tapes that are 
subsequently read into MVS , downloaded via the TCP/IP FTP 
facility to the server, and a conversion program loads the 
data into the system. 

Another source of data for the system comes from ASU's 
FOCUS databases. The FOCUS databases contain extracted 
student information from the student information system 
production database. There are three FOCUS databases: 
Student Records, Financial Aid and Residential Life, which 
are primarily used for end user reporting, New student 
data from these three databases are also downloaded via the 
TCP/IP FTP facility to the telecounseling/recruiting system. 
Future information on financial aid status will be 
transmitted electronically from the Department of Education 
to a LAN server in the Financial Assistance office and 
subsequently downloaded from the financial aid server to the 
Admissions 1 server. 

Information on prospective students is also entered 
manually into DIALOGUE M as a result of student inquiries to 
the Undergraduate Admissions office through mail and 
telephone requests and through programs such as school 
visits and college nights. 



THE SCHEDULE OF EVENTS 



As mentioned previously, once the decision to purchase 
the system had been made, the SIS office had twenty-six 
working days to install the LAN and communications 
equipment. What follows is a schedule of significant 
events, including those twenty-six days, noting certain 
surprises encountered along the way. 

November 12, 1991 Noel/Levitz arrives on campus, conducts 

interviews with several departments and 
demos the DIALOGUE system. 

November 20, 1991 ASU receives Noel/Levitz written 

proposal for "Activating Enrollment 
Potential 11 . 



November 28, 1991 Happy Thanksgiving! 

December 2, 1991 SIS submits a budget outlining the costs 

of a twenty node local area network. 

December 13, 1991 The Senior Vice President and Provost 

approves acquisition of DIALOGUE . 
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December 20, 1991 

December 23, 1991 

December 25, 1991 

December 31, 1991 



January 1, 1992 
January 9, 1992 



January 13, 1992 
January 16, 1992 



January 17, 1992 



Orders for all hardware and software 
purchases processed on CUFS, the 
university's financial system. 

Orders for twenty-eight ethernet 
connections, ten new phone lines, 
eighteen digital phone sets, twenty-two 
head sets processed on CUFS. 

Merry Christmas! 

Request to the Physical Plant Department 
for the installation of two variable air 
volume control units. (This was an 
unanticipated expenditure resulting from 
the decision to locate the server in a 
closet which did not have sufficient 
cooling capacity) . 

Happy New Yearl 

Request to the Electric Shop to install 
an electric outlet in the server closet. 
(This was another unanticipated 
expenditure resulting from the decision 
to locate the server in a closet.) 

Spring semester begins! 

All hardware and software delivered to 
the SIS office. Variable air volume 
controls, electric outlet, Ethernet 
connections, and phone installations 
completed. 

All hardware (20 workstations) checked, 
ethernet boards, workstations, and LAN 
server installed in the Undergraduate 
Admissions office. 



January 18, 1992 All software (operating systems , 

communications, batch files) installed 
on workstations in Undergraduate 
Admissions office. 



January 19, 1992 Access to VM and MVS systems from 20 

workstations tested after 6:00 P.M. 
(Access testing to the VM and MVS 
systems had to be done after 6:00 P.M on 
Sunday because hardware maintenance was 
scheduled for these systems from 9:00 
P.M. Friday the 17th to 6:00 P.M. Sunday 



January 20, 1992 



January 24 , 1992 
January 28, 1992 

January 29, 1992 



the 19th. This was an unanticipated 
scheduling conflict.) 

Hardware and software installation 
complete. 

Happy Martin Luther King Day! 
Target date for system installation. 

TM 

Noel/Levitz installs DIALOGUE software 
on server. 



First phone call made using DIALOGUE 



TM 



POST-IMPLEMENTATION 

Once the first phone call to a prospective student was 
made on January 29, 1992, the system became an integral part 
of the daily activities of the Undergraduate Admissions 
office staff. The impact to the department was enormous. 

One staff line was reassigned to Undergraduate 
Emissions from another Student Affairs department to cover 
the need for a telecounseling supervisor. But, no other new 
full-time staff were hired to manage or support the system. 
Existing staff took on additional responsibilities and/or 
acquired totally new job functions. 

At an assessment and planning session held six months 
after the implementation, the impact on the Undergraduate 
Admissions office activities were identified and categorized 
into seven major functional areas. As the activities were 
formally identified, the impact of the system on the 
department became obvious, along with the realization that 
many of the activities overlapped among the functional 
areas. Each area involved every one of the staff to some 
extent. 



The functional areas identified were: 



Management 
Recruiting 
Data Entry 
Technical Support 
Telecounseling 
Mail Room 
Training 

Management . Management found that they were spending a 
hefty portion of their time in meetings specifically related 
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to the system • These meetings included weekly internal 
meetings with admissions staff, meetings with the vendor to 
develop recruiting plans, meetings with the vendor to define 
refinements to the system to customize it to ASU's needs, 
meetings to promote and gain support of the project from 
other departments within the university, and meetings with 
the upper administration to report on progress being made. 

Management also reorganized the staff by formally 
assigning system responsibilities to existing staff and re- 
assigning several responsibilities to other staff. New 
reporting relationships were established, but for the most 
part, the old reporting relationships continued to be in 
effect, which led to some confusion - depending upon the 
assignment, staff might report to someone other than their 
official supervisor. Sometimes it was unclear what should 
be reported to whom. 

Because the telecounseling/recruiting system was 
ushering in a new era of student recruiting, publications 
needed to be re-thought and re-written. Scripts needed by 
the telecounselors had to be developed. Literature about 
the academic programs at ASU needed to be accumulated and 
prepared for distribution as Undergraduate Admissions 
assumed responsibility for a mail room which would send out 
any information requested by a prospective student. 
"Individualized" correspondence to follow up on phone calls 
had to be developed. Management was heavily involved in 
each of these activities. 

Recruiting . Recruiting activities of the Undergraduate 
Admissions office increased drastically. Prior to the 
advent of the telecounseling/recruiting system, the 
admissions recruitment function was carried out by staff who 
made individual visits to in-state high schools and 
community colleges, hosted special on campus events, and 
were available to meet with students and parents who came to 
visit campus. Out-of-state recruitment was limited to 
occasional college fairs, trips which combined staff 
attendance at professional conferences with short recruiting 
stops at local institutions, and representation by out-of- 
state ASU alumni and current students at hometown events. 

Once the system was operational, the Undergraduate 
Admissions office found themselves with twenty additional 
part-time student employees who had the capability of 
generating hundreds of prospective student contacts per 
night. In most cases each of these contacts produced a 
follow up activity - either a system generated letter with 
accompanying requested information, a referral to another 
department or admissions counselor, and/or a follow up phone 
call . 



In addition to the general increase in recruitment 
activity, the recruitment function also collaborated on the 
design and content of the revised publications, the 
departmental literature, and participated in publicizing the 
recruitment efforts to other university departments. 

Data Entry . The data entry function existed in the 
Undergraduate Admissions office, but (with regard to 
recruitment) had been done on a stand alone PC using an 
admissions developed dBase III+ application. Prior to the 
implementation of the new system, basically only the name 
and address of prospective students was being entered in 
order to produce mailing labels. The new system 
dramatically increased the amount of data being collected 
and input for each student and also required the data entry 
personnel to make some subjective decisions. 

Also, before the new system, inquiries for information 
about the university received by phone or incoming mail only 
required the admissions staff to write down the name and 
address. Now they not only had to learn how to use the new 
system, but they also had to start requesting more 
information from the prospective student. Dat^ entry 
manuals had to be developed and staff slowly converted to 
the new method. 

Technical Support . The functional area noticeably 
experiencing the biggest change as a result of the new 
system was technical support. Prior to the advent of 
DIALOGUE", technical support in Undergraduate Admissions 
was minimal and non-formalized. When the department had a 
problem with their hardware or software, they contacted the 
appropriate on campus agency for assistance. In order to 
enhance their local support, they had recently reclassified 
an existing position to provide departmental computing 
support, with the specific goal of developing a new student 
orientation application. This new position had been filled 
only a short time before the decision was made to acquire 
DIALOGUE . 

The new computing support staff member suddenly found 
his time being consumed by a project that had not even been 
on the agenda at the time of his hire. Not only was he 
supporting the daily computing activities that previously 
existed, he was also thrust into learning the intricacies of 
a new system and assuming the responsibilities of LAN 
administrator. 

Getting new users set up on the network, providing 
requested reports from the new system, interfacing with 
Noel/Levitz personnel to resolve system problems and 
coordinate changes, developing procedures and automating 

16 
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processes to smooth the daily routine soon became a full- 
time job. To relieve some of the responsibility from this 
position, the SIS office was asked to devote a staff member 
50% time to assist Undergraduate Admissions with technical 
support. Undergraduate Admissions is currently in the 
process of hiring a full-time programmer to permanently 
assist in the technical support area. 

Telecounselin g. This functional area was non-existent 
prior to DIALOGUE . Telecounseling affected every other 
functional area. The telecounseling function is primarily 
supported by part-time student employees who work from 3:00 
P.M. to 9:00 P.M, Sunday through Thursday and are supervised 
by a full-time Admissions staff person. 

Due to attrition of the part-time student 
telecounseling staff, keeping a well-trained, fully staffed 
telecounseling team required constant attention from 
management. Scripts used by the telecounselors needed to be 
frequently updated due to changes at the university and the 
implementation of new calling projects. The telecounselors 
performed data entry into the system which generated 
additional output for the muil room and more follow up from 
the full-time recruiting staff. Technical support was 
constantly required to provide needed telecounseling project 
reports and to respond to system problems. 

Management was involved with developing telecounseling 
calling projects. The special projects included: calling 
admitted students to promote orientation programs; calling 
admitted students to encourage interest in on campus 
housing; contacting potential scholarship candidates; 
reminding students of fee payment deadlines; and, surveying 
students who indicated that they had selected another 
institution. Other ongoing projects included: calls based 
on ACT/SAT scores, direct mail follow up; contacts to 
qualify the students 1 interest in ASU; and, the daily follow 
up calls to previous mailings and calls. 

Mail Room . Undergraduate Admissions has always been 
inundated with incoming mail from prospective students 
requesting information about the university. Prior to the 
new system, Undergraduate Admissions had no way of verifying 
when (or if) the requested information was sent to students, 
nor did Undergraduate Admissions send personalized 
correspondence except in special cases. DIALOGUE gave 
them the opportunity to not only generate a letter for every 
student requesting information, but also to include specific 
inserts based on the student 1 s individual needs. 

In order for the mailings to be coordinated and 
smoothly processed each day, Undergraduate Admissions had to 



establish a separate mail room where every available insert 
and mailing piece could be sorted, stocked and stuffed in 
with the letters as required. Staff needed to be trained in 
interpreting the "packing lists" produced by the system and 
found themselves standing at a counter "stuffing" packets 
for several hours each day. Staff also had to be attentive 
to the inventory on hand and alert the appropriate 
department when supplies were running low. 

Printing all of the correspondence soon became an 
issue. Between 500 and 1500 letters were being produced 
daily. Additional functionality of the new system was not 
activated due to concern that the existing department 
printing facilities would not be able to efficiently handle 
the increased printing requirements. Therefore, 
Undergraduate Admissions has not been able to utilize some 
of the features available in the system. 

Training . The training function began by primarily 
concentrating on the telecounseling staff, but eventually 
spread to everyone in the Undergraduate Admissions office. 
With more than fifty full-time staff needing to be trained, 
some at the data entry level, some at the telecounseling 
level, some with respect to report writing, and some in more 
technical areas, training became a big project for the 
department. The department not only did the training, but 
they also had to prepare the training manuals. Since the 
system is still going through a period of change, 
Undergraduate Admissions' internal documentation is 
continuously needing to be updated and staff re-educated on 
the changes. 



ASSESSMENT 

The immediate goal established for the Undergraduate 
Admissions office was to increase enrollment of out-of-state 
new freshmen by 200 students. Out-of-state enrollment of 
new freshmen for the Fall 1992 semester increased by 244. 
The degree to which the new system contributed to the 
achievement of this goal has not yet been determined. The 
Undergraduate Admissions office is "in the process of 
verifying a connection between those students who enrolled 
and whether or not they were contacted by a telecounselor . 
This assessment will be ongoing and the lessons learned 
during this first year will be applied to the recruitment 
efforts for Fall 1993. 

In retrospect, several factors contributed to the 
success of this project. First, senior management's 
initiation and support of this project was visible and 
apparent to all. Getting things done quickly in a large 
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bureaucracy like ASU is often very difficult. Having the 
unequivocal support of senior administration greatly 
facilitates movement through the bureaucratic maze. 

Second, the ability of the Undergraduate Admissions 
office and the Student Information Systems office to 
coordinate with outside vendors, internal service agencies 
and academic departments is not something that happens 
overnight. It depends on prior relationships and networking 
- knowing who to talk to and how to get the job done. 

Third, the ability to install a strategic system in the 
very short period of time was greatly facilitated by the use 
of PC and LAN technology. It is unlikely that a mainframe 
application, even a packaged application like DIALOGUE , 
could have been implemented in less than twenty-six days. 

Finally, the willingness of tlv? Undergraduate 
Admissions staff to accept the challenge and quickly adapt 
to the enormous change in their routine was essential for 
this project to succeed. The Undergraduate Admissions staff 
took the brunt of this "culture shock" and deported 
themselves in a manner that was above and beyond the call of 
duty. 

Telecounseling is a powerful tool. In addition to 
being used to recruit students, it can also be used to 
conduct surveys to identify changes in perceptions and 
attitudes of students. This information will assist 
administrators in their efforts to personalize the 
university experience and respond to changing demands. 



NOTES : 

1 FOCUS is a fourth generation language and database 
management system (4GL/DBMS) and is a registered trademark 
of Information Builders, Inc. 
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ATTACHMENT A 





nAHUWArfc 


FILESERVER: 


(1 unit) 


• 


Everex Step 486/33 EISA 


• 


16MB RAM 


• 


(2) 676 MB SCSI drives 


• 


Monochrome card and monitor 


• 


1.44 MB 3.5 floppy drive 


• 


NE2000 twisted pair 16 bit NIC 


• 


American Power Conversion Smart UPS 90C 


SUPERVISOR'S WORKSTATION: (1 unit) 


• 


HAL-2001 386/25mhz 


• 


8 MB RAM 


• 


80 MB hard disk 


* 


Orchid VGA card 


• 


VGA color monitor 


« 


1.44 MB 3.5 floppy drive 


• 


Internal 2400 baud modem 


• 


HP 5400 DAT 2GB tape backup unit 


• 


3C503 twisted pair 6 bit NIC 


TELECOUNSELOR WORKSTATIONS: (19 units) 


• 


HAL-2001 3S6/25mhz 


• 


4 MB RAM 


• 


40 MB hard disk 


• 


Orchid VGA card 


• 


1.44 MB 3.5 floppy drive 


• 


3C503 twisted pair 8 bit NIC 


UNDERGRADUATE ADMISSIONS EXISTING WORKSTATION UPGRADES: (6 units) 


• 


Forte/I rma boards 


• 


Memory upgrades to 4 MB RAM 


• 


3C503 twisted pair 8 bit NIC 


SIS FILESERVER UPGRADES: 


• 


American Power Conversion Smart UPS 900 


• 


HP 6400 DAT 2GB tape backup unit 


• 


Memory upgrade to 16 MS RAM 


• 


676 MB SCSI drive 


• 


345 MB SCSI drive 


PRINTERS: 




• 


Okidata 393 Plus 


• 


(2) HP III LaserJet 
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ATTACHMENT B 




SOFTWARE 


COMMUNICATIONS: 

NCSA (TCP/IP for FTP and Telnet) 
Forte (PC789)/lrma (E78) 
CloseUp Remote 3.0 


DATABASE MANAGEMENT SYSTEM (DBMS): 
Clarion 2,1 


OPERATING SYSTEMS: 

DOS 5.0 
Novell 3,11 


GUI: 


Windows 3.1 


UPS: 


Powerchute Plus 3.1.4 


TAPE BACKUP: 


Syplus 1.21 


PRINTING: 


Lanspool 3.0 


WORDPROCESSING: 

WordPerfect 5.1 
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Arizona State University believes effective academic 
advisement is an essential aspect of the student's educational 
experience. In the spring of 1990, a Mandatory Advising Task Force 
was organized to assist faculty and staff in meeting their 
commitment to quality academic advising* 

Under the direction of Dr. Kathleen Church, Assistant Vice 
President for Academic Programs, the Mandatory Advising Computer 
System (MACS) Project Team was formed to develop an on-line, 
in-house advising system. The system was to assist advisors track 
a student's advising and academic history, while providing an 
electronic advising signoff that could be used by the registration 
processing. 

The Project Team consisted of representatives from each of the 
colleges, the Registrar's Office, the University Academic Advising 
Center, and the Intercollegiate Athletic Office. Once the 
similarities and differences among all of the advising areas were 
identified, the MACS Project Team was commissioned to develop an 
on-line advising system that would meet the following objectives: 

* Permit each college to control which of its students must 
be advised prior to registration; 

* Provide a uniform format for recording advising sessions; 

* Provide a way to record course-related overrides; 

* Enforce the advising requirements and the advisor's 
recommendations during all types of registration: batch 
registration, on-line registration, and Touch-Tone 
telephone registration (In-Touch) ; and 

* Control who issues signoff s and overrides. 
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In February 1991, MACS was brought on-line to be piloted for 
Fall 1991 registration by the College of Business 
Administration and the College of Education. Four additional 
colleges began using MACS in the next semester and the 
remaining advising areas joined the group for Fall 1992 
registration. 



WHO USES MACS? 

* Colleges use MACS to define groups of students who must be 
advised prior to registration. 

* Advisors use MACS to issue advising signoffs and record course 
recommendations . 

* Faculty members use MACS to issue course -related overrides. 



WHY USE MACS? 

* By using MACS to define groups of students who need to be 
advised, colleges ensure students are identified and notified 
of the advising requirement. Students who are requiredto be 
advised cannot register for classes until the advising signoff 
is issued through MACS. This ensures University and college- 
related advising policies are enforced. 

* By entering course recommendations, advisors document the 
advising sessions and leave an on-line record that can be 
viewed by other advisors immediately or in the following 
semesters. Advisors can choose to enforce course 
recommendations and control the courses in which a student 
may enroll for a given semester. 

* Issuing overrides through MACS reduces the paper flow and 
permits students to register for classes through In-Touch. 
Using MACS in combination with In-Touch reduces the need for 
the student to come to campus for class registration. 



HOW DOES MACS 

MACS was designed to offer the 

* Provide a history of past 
viewed on-line at any tim 



HELP THE ADVISOR? 

following features: 

advising sessions, which can be 
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* Permit advisors to enter notes on-line that can be viewed by 
other advisors or can serve as reminders for future advising 
sessions , 

* Provide a summary of the student 1 s admission profile. This 
snapshot is particularly important when working with freshmen, 

* Summarize semester and cumulative GPA's, Probation status and 
academic performance trends can be viewed at a glance. 

* List the courses a student has enrolled in for each semester 
at ASU, along with the grade, 

* Highlight athletes and Honors College students. 

* Identify professional program status. 



WHAT IS THE ADVANTAGE TO ENTERING OVERRIDES ON MACS? 

MACS can be used to issue course-related overrides; such as, 
course restrictions, time conflicts, and capacity limits, 

* Overrides issued through MACS can be used by all three types 
of registration to enroll a student in a class, 

* An expiration date can be entered for each override issued, 
thereby giving the college control over the length of time in 
which the student may use the override, 

* MACS maintains a complete history of overrides issued and used 
by the s^dent for each semester. It also provides a list of 
overrides the student needed but did not have when the course 
was requested. 



HOW SECURE IS MACS? 

Each advising area has a security administrator who controls 
update access to MACS. The security administrator determines who 
may issue advising signoffs for its students and course-related 
overrides for its courses. These security profiles are built 
on-line and go into effect immediately, 

* Advisors from one college may not issue signoffs for students 
from another college unless the security administrator 
has granted permission through an on-line authorization 
screen. 
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* Each college may limit override authorization to specific 
types of overrides, departments, or campuses. 

* Once the semester ends, advising signoffs and course overrides 
for the semester cannot be altered. They become a permanent 
part of the student's record. 



WHAT IMPACT DOES MACS HAVE ON THE STUDENTS? 

Students identified as "mandatory advisees 11 may not register 
for classes until an advisor has issued a signoff /through MACS • 
This ensures that the student receives direction prior to class 
scheduling. 

* Students who have the MACS signoff may register for classes 
using batch registration, cn-line registration, or In-Touch. 
This provides the students vith options to accommodate their 
already busy schedules. 

* Students who receive course-related overrides issued through 
MACS do not have to carry a piece of paper to the Registrar's 
Site to schedule a class. These students may now pick up a 
phone and schedule these classes at their convenience. 



STATISTICS 

Fall 1992 registration was the first semester in which all of 
the advising units used MACS. Of the approximately 44,000 students 
enrolled in classes for that Fall, over 15,000 students were 
advised through MACS prior to scheduling classes. 

Over 9,000 course-related overrides were issued through MACS 
and used by students to schedule classes they were not originally 
able to obtain. 



OPERATING ENVIRONMENT 

Hardware: IBM ^noo-SOOE. The mainframe has 128 megabytes of main 
memory and 128 megabytes of expanded storage. It is 
logically partitioned into multiple systems via PR/SM. 
The Administrative partition has 40 megabytes of 
expanded storage. 

Software: IDMS Database management system 
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ADS/O 

COBOL/COBOL II 

EASYTRIEVE PLUS 
IDMS-DC 



Programming language used to 
develop MACS on-line screens 

Programming language used to develop 
batch extract programs and on-line 
subroutines 

Programming language used to develop 

TP monitor used with COBOL II for 
onl ine registration 
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Automating the Housing Process 

at 

Florida State University 



Danny R. Hawkins 
Assistant Director 
Administrative Information Systems 
Florida State University 
008 Westcott Building (R-24) 
Tallahassee, Florida 32306 
(904) 644*2840 



Brian Buckner 
Coordinator of Housing Systems 
Administrative Information Systems 
Florida State University 
108 Diffenbaugh Building (R-18) 
Tallahassee, Florida 32306 
(904) 644-2495 



The University Setting 

The Florida State University (FSU) is located in the gently rolling hills of Northern 
Florida, half-way between the southern border of Georgia and the Gulf of Mexico, in 
Tallahassee, the capital, city of Florida. Tallahassee is not only Florida's capital, but one 
of its oldest and fastest growing cities, with a population in excess of 175,000. More than 
100 state and federal agencies furnish our students with opportunities for internships, 
research, and work-study programs matching all areas of academic interest. In addition, 
Tallahassee affords a rich offering of social, cultural, and recreational activities, making it 
an excellent place in which to live, study, and grow. 1 

FSU is one of nine universities of the State University System of Florida. It was 
established as the Seminary West of the Suwannee by an act of the Florida Legislature in 
1851 and first offered instruction at the postsecondary level in 1857. Its Tallahassee 
campus has been the site of an institution or higher education longer than any other site in 
the state. In 1905. the Buckman Act reorganized higher education in the state and 
designated the Tallahassee school as the Florida Female College. In 1909, it was renamed 
Florida State College for Women. In 1947, the school returned to co-educational status, 
and the name was changed to The Florida State University. It has grown from an 
enrollment of 2,583 in 1946 to an enrollment of 28,512 in the Fall Semester 1992. 2 



An Evolution of Administrative Systems 

Prior to 1985, information systems at Florida State were managed bv the independent 
programming staffs of Academic Data Systems, the University Controller, the offices of 
Business Services and Budget and Analysis, and the Division of Student Affairs. Each of 
these units had been developing and supporting various computer applications for many 
years. Some units had made major advances with systems and technology, others had not. 
While the separate units coordinated projects when there was a major need or an overlap 
of responsibilities, each unit developed systems pretty much independently and for the 
specific and individual nec ' \ of their users. As a consequence, there was much 
redundancy of data, as well as effort, and very little integration between the various 
administrative systems. 
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Realizing the need for better integrated and more consistent data, and especially a 
more coordinated and comprehensive view of application design and development, the 
University Provost combined all of these units into Administrative Information Systems 
(AIS) in 1985. Prior to this, support for designing and writing a new Housing System had 
been lost in a maze of "bickering" about resource allocation and project prion ties, and the 
entire application was supported by only .3 FTE. However, as part of the consolidation 
of IS staffs, the Housing Office and Division of Student Affairs committed additional 
resources, and AIS and the Housing Office launched a major system develop effort. 



Resident Housing at FSU 

FSU has approximately 4000 undergraduate students living in 12 residential facilities 
ranging in capacity from 134 to 574 students, and another 1000 graduate students livingin 
university apartments. Each year, the Housing Office distributes nearly 12,000 
applications, of which almost 8000 are returned and processed. Students have available a 
wide variety of campus living accommodations, options, and preferences, such as 12 on 
campus dormitories, 8 room types, 6 special programs, 5 visitation options, and may 
choose up to 3 roommates. Additionally, 4 different payment methods are offered and 18 
possible rental rates based on the type of room and building assigned. 3 All housing rental 
tees are established by The Florida State University and are subject to approval by the 
Board of Regents. University Housing is a self-supporting auxiliary and rental rates must 
reflect operating costs. 4 



Doing Things the "Hard Way" 

When AIS was established in 1985 Florida State was still essentially performing the 
resident housing process manually. Two online computer files were available and 
financial data such as charges and payments were maintained in a revolving keypunch card 
cabinet. 

The Housing Data Base: Once a week, as students were admitted to the university, the 
Admissions File was referenced to produce labels to mail these students housing 
application and information packets. As completed housing applications were returned to 
the Housing Office, they were data-entered into the "Housing Data Base" (actually a 
keyed-sequential VSAM file). This file was primarily used for rudimentary reporting and 
to easily view applicant data online. It was not integrated with other university systems or 
other housing functions. It contained redundant data which was also stored on the 
Admissions File and the Student Data Base, and keeping the housing data in sync with 
these files required manual notification between offices or by students. Therefore, the 
"Housing Data Base" usually contained obsolete and inaccurate data and was not very 
reliable. 

The Room Assignment Process: The other online computer file was essentially the 
"Room Assignments File" and included dormitory names (cryptic abbreviations), room 
numbers of all available rooms, and social security numbers and names of students 
assigned to each room (see sample screen on next page). Prior to 1990, determining an 
assignment was completely a manual process. All 8,000 applications were laid on desks 
and sorted by first-hall choice. Once this first step was completed, another sort was done 
based on application date and priority number. The matching of roommates and desired 
room types followed. Once a hall was filled, remaining students were resorted using their 
second-hall choice, and the whole process repeated. After all twelve dorms were filled, 
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the social security numbers, U-boxes (campus mail boxes) and room rates of each student 
were updated to the Room Assignments File. During this manual processing time, 
responses to student inquires were slow or non-existent because the Housing staff could 
not determine where, in the over 4,000 rooms, a student was assigned, or even if the 
student had an assignment. 5 Needless to say, this was a very laborious and 
time-consuming process, taking 3 employees approximately 3 months to complete. 



• Sample Screen (Old System) — 












HOUSING ROOM ASSIGNMENTS 






BLDG 


ROOM 


SOC SEC NUN 


STUDENT NAME 


UBOX 


RATE 


CAWT 


112A 


123456789 


SEMINOLE GOOD 


1234 


425.00 


DEVI 


106A 


299123000 


CONFERENCE ACC 


1256 


375.50 


LAND 


234 


129076459 


GATOR BAD BOY 


2390 


450.00 


* 


* 






* 


* 


* 


* 


* 




* 





Processing Charges and Payments: After the Room Assignments File was built each term, 
a batch job was processed punching an IBM card which contained each student's SSN, 
name, room location, charge type, and room charge. These cards were then interpreted 
on an old IBM 529 Interpreter (yes, the kind requiring a wired board), sorted by student 
SSN, and merged on an IBM 085 Collator (again, the kind requiring a board) with other 
outstanding charges. This combined "Charges File" was placed in file drawers in the 
Cashier's Office, and each time a charge was paid by a student, the "charge card" was 
manually pulled and the amount of the payment written on the card. At the end of each 
day, a keypunch operator would punch the amount of the payment in the card, and the 
cards were sorted and a proof listing produced on the computer. Corrections were made 
to the cards and additional proof listings produced until the cards" balanced with the cash 
drawer. As each days business was balanced, the reports were kept and the cards collated 
to produce an end-of~month file and reports. As you can probably guess, cards and 
reports would get lost or destroyed, and reconciling was a continuous nightmare. 
Auditors didn't particularly like the process either, and on several occasions recommended 
that the process oe automated. It was these less-tfian-favorable audits that eventually were 
the catalyst to getting the system rewritten. 



A Housing System for the 90s 

Like the old system, the new Housing System revolves around three subsystems and 
files: (1) housing applications and information are still mailed to admitted students and 
application data is entered into the system; (2) room assignments are now processed via 
an automated process; and (3) cnarges are automatically computed and payments 
processed online and realtime. Additionally, the new system automates many other 
processes, provides more timely and accurate information, and integrates with other 
university files such as Admissions, Student Data Base, and Accounts Receivable. 

University Master Menu: One major enhancement to the Housing System is its inclusion 
in the University Master Menu and AIS Security systems. The Master Menu provides a 
consistent and reliable method for terminal users to enter online administrative 
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applications. AIS Security controls User access to specifically authorized screens and data 
elements Ail of FSU's administrative applications will eventually use the Master Menu 
System, but it has become apparent that many of our users (we like to call them Power 
Users") prefer to rapidly move from screen to screen without having to navigate through 
menus In order to make our applications more flexible for these users, we are currently 
piloting a General Transfer System which will allow the entry of a transfer code on each 
screen and automatically move to the desired system and screen. (Of course, one must 
have security clearance defined in the AIS Security System to make such a transfer.) 

Another feature of the Master Menu System our users like is the News display 
bulletin. This feature will eventually exist on the master menus of all systems and provide 
users a method to flash notices and information much easier and Quicker than sending 
E-mail, memos, or making phone calls. When using the University Master Menu to move 
to the Housing System, one enters selection 'B' to receive the Housing Master Menu as 
seen on page 5. 



p= University Master Menu 



FSU ADMINISTRATIVE INFORMATION SYSTEMS 
APPLICATIONS MASTER MENU 



DEPT SECURITY COORDINATOR: 
NAME : RAY WESTER 
PHONE: 644-2495 



A - STUDENT ACADEMIC 

B - STUDENT AFFAIRS 

C - STUDENT FINANCIAL 

D - FINANCIAL AID 

E - PERSONNEL/PAYROLL 

F - AUXILIARY SYSTEMS 

G - FIN/ACCOUNTING 

H - ADDRESSES 

I - UNIVERSITY SUPPORT 

X - EXIT MENU 

Z - EXIT MENU WITH LOGOFF 

ENTER LETTER OF SELECTION: ? 

PF1: LIST OF APPLICATIONS 



++++++ AIS NEWS ++++++ 



WELCOME TO THE FLORIDA STATE UNIVERSITY 



MAS 


T E R 


M 


E N 


U S Y S T 


E M 




***** 




***** 






★★ 


★ 




** ** 






** 






** ** 






** 


**** 


** ** 






** 


* 




** ** 






***** 




***** 




* ** 


***** 


** 


***** 


**** 


** ** 


** 


** 


** 


** 


** 


* * ** 


** 


** 


★★ 


**** 


** 


** * * 


** 


*★ 


** 


★* 


*** 


** ** 


** 


** 


** 


** 


** 


** * 


***** 


****** ****** 


**** 



PF2 OR PA2: EXIT 



Housing Master Menu: This menu is the gateway to all Housing files and online 
functions. From it one may select any of the major subsystems (Student, Assignment, or 
Fiscal), update their user access password, and broadcast news (if authorized) to all users 
of the Housing System. 
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Housing Master Menu 



THE FLORIDA STATE UNIVERSITY 
HOUSING MASTER MENU 



DATE: 12/10/92 



A - STUDENT INFORMATION 
B - ASSIGNMENT INFORMATION 
C - FISCAL INFORMATION 

P - UPDATE PASSWORD 

U - UPDATE NEWS 



HOUSING NEWS ******** 
WELCOME * 

TO THE NEW * 

* * 

* UNIVERSITY HOUSING * 

MENU! * 



SELECTION: ? 

PASSWORD: ???????? 

NEW PASSWORD: ???????? 

VERIFY NEW PASSWORD: ???????? 



* * 

* DETAILED MENUS EXIST FOR OPTIONS A -> C. * 

* THESE MENUS, HOWEVER, ARE CONTROLLED VIA * 

* THE AIS SECURITY SYSTEM. TO OBTAIN * 

* AUTHORIZATION TO VIEW THESE MENUS, * 

* CONTACT KEN NIELSEN AT 644-8857. * 



MESSAGE: ENTER THE LETTER OF THE DESIRED SELECTION AND PRESS ENTER- 
PRESS: PF1=HELP, PF2=AIS MENU, PF3=SA MENU, PF5=NAME BROWSE. 



The Student Information Subsystem; Accessed via menu selection 'A' from the Housing 
Master Menu, this screen provides an opportunity to input, update, cancel, and reinstate 
housing applications; view application information; review a student's housing activity 
history; and update information such as student name, SSN, and permanent address. As 
can be seen, several functions are available. For instance, selection 'SA' presents the 
Student Information Inquiry screen. 



= Student Information Subsystem Menu 



THE FLORIDA STATE UNIVERSITY 
HOUSING STUDENT INFORMATION MENU 



DATE: 12/10/92 



APPLICATIONS: 
AA - ADD 

AB - INQUIRY/UPDATE 
AC - CANCEL (N/A) 
AD - REINSTATE (N/A) 

SELECTION: ?? 



STUDENT INFO: 

SA - INQUIRY/UPDATE 

SB • HISTORY 



CHANGE FUNCTIONS: 
CA - NAME 
CB - SSN 

CC - PERMANENT ADDRESS 



SSN: ??? ?? ???? NAME: ?????????????????????????? 

TERM: ? YEAR: ?? 



MESSAGE: ENTER THE LETTER OF THE DESIRED SELECTION AND PRESS ENTER. 
PRESS: PF1=HELP, PF2=AIS MENU, PF3=HSG MENU, PF5=NAME BROWSE. 
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Student Information Inquiry: This is the basic information screen for students in 
university housing. The student's SSN is the primary key to the file and also links the 
Housing System to other university files. For instance, name, birth date, sex, and 
permanent address are retrieved from either the Admissions File, Student Data Base, or 
Centralized Address File. The other data is entered by the Housing Office or retrieved 
from other housing files such as the Room Assignments File. An interesting aid for 
Housing staff is the ability of the system to display certain informational messages such as 
ENROLLED IN HONORS. 

Other data which is collected in the housing application and university admissions 
process and which is available on six other screens includes: Handicap information; 
Smoking Preference; Music Practice; Special Housing Options such as Prepaid College, 
Honors, or Genesis; Visitation Preference; Air Conditioner Need; Preference Ranking of 
Hall/Floor/Room, Roommate, and Room Type; Dormitory Choices; Room Type 
Preferences; and Roommate Preferences. The History Screen (selection SB on the 
Student Information Subsystem Menu) provides a chronological history of each transaction 
processed for each housing student. The CHANGE FUNCTIONS provide a consistent 
and easy manner to update names and addresses and change SSNs. These functions 
actually link to, and update, other university files in order to keep files in sync and 
eliminate the need for redundant data. 



1 Student Information Inquiry 






STUDENT INFORMATION - 


INQUIRY 




SSN: 589 99 9999 NAME: 


SEMINOLE GOOD GUY 




BIRTHDATE: 06 30 74 PRIVACY: 


H PERMANENT ADDRESS: 






499 WALKER AVE 




SEX: M TYPE: S • 


STUDENT TALLAHASSEE 


FL 32399 




( 904 ) 321-8977 




ENROLLED IN HONORS 






APPLICATION INFORMATION: 




REJECT: N 


INITIAL APPL: TERM: 9 92 


DATE: 07 07 92 PRIORITY: 3514 




FALL/SPRING RENEW: TERM: 1 93 


DATE: 11 29 92 


TYPE: 


SUMMER RENEW: TERM: 


DATE: 


TYPE: 


HOUSING ASSIGNMENT FOR 1/93: 


0312 BROWARD HALL 






U-BOX 66376 






< 904 ) 853 - 1719 




MESSAGE: INQUIRY COMPLETE - PRESS PF6 TO UPDATE OR PF9 TO DELETE. 




PRESS: PF1=HELP, PF2=AIS MENU, 


PF3=SI MENU, PF4=»SG MENU, PF5-NAHE BROWSE = 
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Room Assignments Subsystem: This subsystem provides eleven screens to perform four 
basic functions: (1) ada, change, or delete a student's assignment online or to browse the 
Room Assignment File; (2) update the Room Assignment File with new buildings and 
rooms; (3) update room rates: and (4) update, activate, deactivate, and assign campus post 
office boxes. An example or the Room Assignment Browse screen follows at the bottom 
of the page. 



Room Assignments Subsystem Menu 



THE FLORIDA STATE UNIVERSITY 
HOUSING ROOM ASSIGNMENT MENU 



ASSIGNMENTS: 
AA - BROWSE 
INQUIRY 

HAKE ASSIGNMENTS 
REMOVE ASSIGNMENTS 
UPDATE DATES 
MOVE REQUESTS (N/A) 
CHECK IN (N/A) 
IN HALL MOVES (N/A) 
NO SHOWS (N/A) 
IKTENT TO VACATE (N/A) 
CHECK OUT (N/A) 



AB 
AC 



AD 
AE 
AF 
AG 
AH 
AI 



ROOMS/APTS: 
BA • ADD (N/A) 
BROWSE 

CHANGE INFORMATION 
DELETE 

MAINTENANCE (N/A) 
HISTORY (N/A) 
STATISTICS (N/A) 



BB - 



BC 
BD 
BE 



ROOM RATES: 
RA - ADD 
RB - BROWSE 

• DELETE 

• UPDATE AMOUNTS 



SELECTION: ?? 



DATE: 12/10/92 



U-BOXES: 
UA - ADD 



UB 



UC 
UD 



ACTIVATE 
BROWSE 

MAKE ASSIGNMENT 
REMOVE ASSIGNMENT 
STOP CANCELLATION 
DELETE 



SPECIAL FUNCTIONS: 
SA • ASSIGNMENT TERMS 



TERM: ? BLDG: ???? 

SSN: ??? ?? ???? NAME: 
U-BOX: ???? 



ROOM: ???? 

??????????????????????? 



MESSAGE: ENTER THE LETTER OF THE DESIRED SELECTION AND PRESS ENTER. 
PRESS: PF1=HELP, PF2=AIS MENU, PF3=HSG MENU, PF5=NAME BROWSE. 



Room Assignments Browse 



TERM: 9 



ASSIGNMENTS - BROWSE 
BLDG: LAND ROOM NUM: 0404 BED: B 



BUILDING KEY SOC SEC NUM 



9 LAND 0343 B 
9 LAND 0344 A 
9 LAND 0344 B 
9 LAND 0345 A 
9 LAND 0345 B 



999-28-1922 
999-72-9003 
999-55-8644 
999-36-4226 
999-24-7738 



STUDENT NAME 
SEMINOLE JOHN Q 
SMITH MARY JANE 
COLLEGE JOE EDWARD 
APPLETON CRABBY J 
HAWKINS DANNY R 



TYPE SEX RATE PHONE UBOX 

DBL M 899.00 853-2719 0423 

DBL M 1040.00 853-3699 3202 

DBL M 1040.00 853-3699 0511 

DWB M 1195.00 853-1893 0184 

DWB M 1195.00 853-1893 0883 



MESSAGE: PRESS PF7=PAGE UP, PF8=PAGE DOWN. 

PRESS: PF1=HELP, PF2=AIS MENU, PF3=AI MENU, PF4=HSG MENU, PF5-NAME BROWSE. 
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Fiscal Information Subsystem: This subsystem provides thirteen screens to process and 
display aata related to charges, payments, and deferments. As can be seen from the 
Housing Fiscal Menu, there are several different functions available to process payments. 
Charges are generally generated automatically by procedures such as the Automated 
Assignment or Late Fee Processes, but charges can be manually entered. 



Fiscal Information Subsystem Menu 



THE FLORIDA STATE UNIVERSITY 
HOUSING FISCAL HENU 



DATE: 12/10/92 



CHARGES: 
CA - ADD 
CB - BROWSE 
CC - ADJUST 

- CANCEL 

- CHANGE FLAGS 

- CHANGE DEFER CODE 

- DELETE 

- REINSTATE 

CHARGE COOES: 
BA - ADD (N/A) 
BB - BROWSE <N/A) 
BC - UPDATE (N/A) 



SSN: ??? ?? ???? NAME: ????????????????????? 

TERM: ? YEAR: ?? 



MESSAGE: ENTER THE LETTER OF THE DESIRED SELECTION AND PRESS ENTER. 
PRESS: PF1=HELP, PF2=AIS MENU, PF3=HSG MENU, PF5=NAME BROWSE. 



ADV PAYMENTS 
AA - ADD 
AB - APPLY 

- BACK OUT 

- BROWSE 

- FORFEIT 

- REFUND 

PAYMENTS: 

PA - ADD 

PB - BROWSE 

PC - CHANGE PYMT CODE 

- CHANGE APPLY MM/YY 

- DELETE 

- REINSTATE FORFEITS 
SELECTION: ?? 



MONTHLY F/A DEFERMENTS: 
FA - ADD 
FB - ADJUST 

- BROWSE 

- DELETE 

- UPDATE 

SPECIAL FUNCTIONS: 

SA - ADD TERMS 

SB - BROWSE/UPDATE TERMS 

SC - RECEIPT LOCK 



I Charges Browse — — 




CHARGES 


- BROWSE 




SSN: 999 


05 8410 


NAME 


: COLLEGE 


JOE MAJOR 


TERM/YEAR: 


MODES: X 


- DETAIL INFORMATION 




COMPLETE BALANCE DUE: 1040.00 


M TERM 
9/92 
9/92 


CHG DATE 
08/16/92 
TERM 


SEQ NUM 
HU 00318 
TOTALS: 


CHG AMT 

1040.00 
1040.00 


BAL DUE 
0.00 
0.00 


PD AMT DESCRIPTION 
1040.00 DORM RENT 
1040.00 


1/93 
1/93 


01/04/93 
TERM 


HU 02521 
TOTALS: 


1040.00 
1040.00 


1040.00 
1040.00 


0.00 DORM RENT 
0.00 


MESSAGE: 
PRESS: 


»> END OF 
PF1=HELP, 


REQUESTED DATA! «< 
PF2*AIS MENU, PF3=FI 


PRESS PF7=PAGE UP, PF6=CHRG UPDATE. 
MENU, PF4=HSG MENU, PF5=NAME BROWSE. 
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I Payments Browse 



PAYMENTS - BROWSE 



SSN: 999 05 8410 



NAME: COLLEGE JOE MAJOR 



TERM/YEAR: 



MOOES: X - DETAIL INFORMATION 



CHARGE PAID ORIG 



TRNSFER 
RCPT 



PAID DIS 



M TERM DATE DATE RCPT 



9/92 08/16/92 03/02/92 092062 
9/92 08/16/92 06/23/92 092175 
9/92 TERM TOTALS: 



BUDGET AMT NUM DESCRIPTION 

722700062 225.00 01 DORM RENT 
722700062 815.00 01 DORM RENT 



1040.00 



MESSAGE: »> END OF REQUESTED DATA! «< PRESS PF7=PAGE UP, PF6=UPDT PAYMENTS. 
PRESS: PF1=HELP, PF2=AIS MENU, PF3=FI MENU, PF4=HSG MENU, PF5=NAME BROWSE. 



Automating Housing Assignments 

The most exciting new function available in the new Housing System is the 
Automated Assignment Process. It consists of two components which are run in batch. 
The first component is used to create the assignment order and the second is used to search 
through dormitories looking for the assignment that best meets a given student's needs and 
preferences. 

Creating the Assignment Order: The first step in creating the assignment order is to 
determine if the student is in any Special Programs. This information is located on the 
Housing Application. Admissions, and Student Data Base files. Special Programs 
include: Honors and Scholars, Florida Pre-Paid College Plan, Genesis, and Transfer 
Students. Each of these Special Programs are located in designated dorms and rooms. 
This first step ensures a Special Programs student will be assigned a room in the proper 
area. 

The program next examines roommate requests. Each student may request up to 
three roommates. In order to be assigned with requested roommates, all parties need to 
request each other, and must agree that roommate preference is the highest priority 
preference. The program also checks to see if all parties are in agreement concerning 
visitation and air conditioning preferences. Roommate requests that do not properly match 
are printed on an error report and resolved by the Housing staff. 

The final step includes sorting students in application date and priority number 
sequence. The earlier an application is received, the higher the priority will be. 
However, exceptions to this sequence are allowed. For instance, Honors students are 
always assignee! first, and roommates who request each other are sorted using the most 
recent application date and lowest priority number. 

Assigning Rooms: If a student requested a roommate, the program first determines if the 
roommate has been assigned a room. If so, the student is immediately assigned to the 
same room. If the roommate has not been assigned, the program finds the best possible 
assignment using the process described in the following paragraph. 
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To make the best possible assignment, the program first looks at the student's dorm 
choice and determines if it meets the air conditioning preference. If not, the next dorm is 
searched. If the air conditioning preference is matched, the program searches for rooms 
with the desired room type. Once found, the program searches for a match on visitation 
preference. Students are only assigned to a room if the dorm and floor matches the 
visitation preference. 

Once a room is found meeting all the student's preferences, the program checks to 
see if the room is already assigned. If not, the assignment is made. Otherwise, more 
checks are made to ensure the roommates are compatible. The roommate matching 
criteria includes questions about smoking preferences, wake up times, and study habits. If 
all criteria match, the student is assigned. If students are not completely compatible, the 
program again begins the search for the best room assignment, if no other rooms are 
found in the desired dorm, partial compatibility is checked. However, smoking 
preferences must match. Smokers will not oe assigned rooms with non-smokers. This 
process is followed for each of a student's four dorm choices, If no room is available in 
any of the requested dorms, the program searches down a list of the most desired dorms 
on campus. Again, an attempt is made to find the best possible assignment given a 
student's preferences and requests. Once the assignment is made, the student's name, 
SSN, move-in-date, move-out-date, U-box, and room rate are automatically updated to the 
Room Assignment File and a transaction log record is generated to the History File, 

The Automated Assignment Process has been a huge success for both students and 
Housing Office staff. Students find out much sooner what their assignment is and who 
their roommates are. The Housing staff doesn't spend months manually assigning rooms 
and are available to spend more time with students who have special proolems, 

Fu ture Enhancements 

Most of FSU's housing students are undergraduates and the new Housing System is 
targeted primarily at them. Maintaining the operation of 996 graduate apartments with 
thirty day leases continues to be a strain and presently requires a huge amount of 
paperwork. Design work has been completed and automating this process is being 
planned. In the future, automated check-in procedures will initiate rent, produce a copy 
of the key receipt, update the Room Assignment File, produce a housing account balance 
statement, and update the Student Data Base. Future check-out procedures will stop rent 
and calculate a prorated balance, notify staff of apartments available for inspection and 
reassignment, and update the Student Data Base. 

Another major effort will move some housing operations out into the dormitories 
providing easier access for students. Presently, students must come to the Central Office 
to request room changes, submit applications for future terms, and verify account 
balances. They must also visit other offices such as the Registrar, Controller, Financial 
Aid, etc. to take care of various business. The University is considering an expansion of 
its Self-Inquiry System and development of Windows-based GUI interfaces to include 
many of these functions. 
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The new Housing System has made life much easier for the Housing Office and 
students, and saves hundreds of man-hours a year. Data is much more reliable and 
information is more available to make informed decisions. Excellent fiscal controls are 
now in place and the latest business audit produced zero criticisms. 

"Caring and Sharing" is the motto of the Division of Student Affairs. This project 
demonstrates that a major development effort can be successful when this motto ana a 
team effort are applied. 



FOOTNOTES 

1 General Bulletin, The Florida State University, 1991-1992, page 9. 

2 Florida State University Facts, Institutional Research Section, Budget and Analysis, Fall 

1992. 

3 Burig, Bill, ACUHO-I Article, An Exploration of Housing Automated Systems at 

Florida State University, September, 1992. 

4 General Bulletin, The Florida State University, 1991-1992, page 43. 

5 Burig, Bill and Nielsen, Ken, Computerized Room Assignments and Information 

Management - Seminole dtyle, presentation, 1992 SEAHO Conference, Memphis, 
Tennessee. 
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The delicate balance between using technology and providing people- 
oriented services is a constant challenge to student academic support units on the 
campus. Certainly the use of technology to relieve clerical burdens and enable 
people to be more student-centered satisfies the mission of college student 
services. Just as important, timing or delivery of academic planning information 
is critical to students, faculty, and professional advisors. Thus the ideal blend is 
to use machines to provide the timely distribution of information and allow 
academic support/services personnel to assist students individually beyond the 
routine. Academic Information Management (AIM), as described in this paper, 
embodies the following three elements: (1) providing students critical academic 
planning information when they need it, (2) assessing and providing access to 
student academic information for the academic community, and (3) freeing people 
to individualize services. In short, AIM's purpose is to effectively distribute 
academic planning information to student and faculty colleagues. 



AIM S DEVELOPMENT AND PRECURSORS 

For several years at BYU, students (via paper) and faculty/professional 
advisors (via terminal) have received an Advisement by Computer (ABC) report 
each semester. Generally, these reports are made available at the beginning of the 
semester to (1) verify current registration and (2) provide academic planning 
information for a subsequent semester. The ABC report, implemented in 1979, 
provides students and advisors access to current curriculum degree requirements. 

Advisement by Computer (ABC) 

The ABC system provides the user with immediate and direct access to the 
curriculum degree requirements and student academic records. The user can 
generate an individual progress report on request. When the student's name or 
social security number is entered, the computer program locates the student's 
academic record, matches it with the degree requirements for the semester the 
student officially entered the degree program, and displays the results on the 
terminal screen in two to three seconds. If a hard-copy record is desired, the 
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request is entered in the computer and the report is printed immediately. ABC 
progress reports are mailed to students each term of their enrollment. 

The format and features of the ABC report are divided into the following 
three sections: (1) university graduation requirements, (2) major requirements, 
and (3) current enrollment and unofficial transcript. Each of these sections is 
described below. 

University Graduation Requirements 

This section contains biographical information (the students name, 
address, college, major, and expected graduation date) and university graduation 
requirements (including general education requirements). In addition to listing the 
number and hours of required classes and the classes completed, this portion 
indicates remaining deficiencies and lists current classes that will fill them. 

Major Requirements 

This section lists the requirements for the student's declared major. It 
contains biographical information (including the term in which the student declared 
his or her major) and the requirements of the major (grouped in a logical sequence 
recommended by the department). The required courses are listed on the left, 
followed by what classes were used to complete the requirements, the grade 
received and number of credit hours for each class. If the department has 
authorized waivers, substitutions, or transfer equivalencies, these are also shown. 
Text information may be added to the course groups or placed at the top of this 
section. The address and phone number of the college advisement center as well 
as the name of the assigned faculty advisor are always included as the last entry 
of this section. 

Current Enrollment and Unofficial Transcript 

This section is divided into two parts: (1) current enrollment and (2) an 
unofficial transcripL The current enrollment serves as a verification of the 
student's registration, because listing the class title, section number, and credit 
hours are listed for each class. The unofficial transcript lists all courses the 
student has completed at BYU or elsewhere. A semester CPA is given for each 
semester completed at BYU, as well as a summary of credits listing overall GPA 
and BYU GPA. 



Summary of Features 



The computer-assisted advisement report 

*States graduation requirements and tracks course completion and 
deficiencies. 

^Categorizes requirements within the major (college, department, major, 
and emphasis). 

^Individually tailors and tracks an approved degree program. 

Tracks major requirements in groups by class, semester hours, and 

various combinations. 

*Shows narrative information as needed. 

^Includes all institutional, transfer, and other credit such as (AP, CLEP, 
or military). 

*Tracks changes in major requirements as often as every semester. 
*Maintains each student's major requirements based on the date of entry 
into the major. 

*Shows substitution courses, waivers, and transfer equivalencies. 
^Applies current enrollment to graduation requirements. 
^Indicates courses that have been repeated. 
^Distinguishes between acceptable and unacceptable grades. 

In summary, the advisement by computer report provides various 
advantages for the student, advisor, and institution: 

THE STUDENT: 

Convenient access to critical planning information, accurate 
information, immediate feedback, and a sense of control in 
academic planning. 

THE ADVISOR: 

Reduces time in evaluating students for graduation, improves 
accuracy of advisement, simplifies obtaining information on 
academic requirements, and makes up-to-date information readily 
available. 

THE INSTITUTION: 

Provides clerical relief, professionalizes the advising program, 
supports cost effective resource management, and deemphasizes 
bureaucratic tendencies of an institution. 
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Touch-Tone Telephone Registration 

Another aspect of AIM ! s development includes BYU's touch-tone 
telephone (TTT) registration system, implemented in 1986. TTT registration 
continues to be a very successful program because (1) almost everyone in the 
country has access to a TTT, and (2) it gives simple, direct access to the 
university's registration system. It has proven to be very popular, but is limited 
to the telephone keypad. A few years ago, we developed a series of TTT 
programs like those available in TP (terminal process) form for financial aid, 
admissions, and advisement. But we disbanded our work because it became 
obvious that the interaction between user and machine would be much too 
cumbersome. We literally developed pages of instructions and TTT dialogue that 
guided the user through such programs as fulfillment of general education 
requirements, address/phone change, grades and BYU credit, and major shopping. 

Both technologies- ABC reports and TTT registration have played a critical 
role in the development of student information management. Their success 
contributed to the expansion and accessibility of information in a new and 
combined program known on our campus as Academic Information Management 
(AIM). It was a natural evolution. Perhaps it would have been possible to develop 
AIM initially or essentially bypass these earlier developments. However, 
previous experience and critical work already in place paved the way for a smooth 
and successful transition to a new dimension of delivering student academic 
planning information. Clearly, what we know about student information systems 
in 1993 is much different than it was in 1978! 

College Advisement Centers(CAC) 

College Advisement Centers (CAC) like the ABC and TTT, also became 
an important forerunner to the successful implementation of AIM. Advisors are 
usually the first and most consistent contact between students and the institution. 
Within the advisor's office, students and the system often meet face-to-face. Here 
is where advisement center personnel encourage students to experiment with AIM 
and finally integrate this new program into the advisement system. 

Since CACs play an integral and collaborative role with BYU's current 
programs in TTT and ABC, it was only natural that they should intertwine with 
AIM. In the context of developing AIM, advisors who are in the unique position 
to represent the institution to the student, as well as represent the student to the 
institution, became a critical sounding board. Because CACs profoundly influence 
the success of technical programs like AIM, it may be helpful to outline their role 
in the institution. The personnel who staff these CACs represent the delicate 
balance between the use of technology and providing people-oriented services. 



The CAC is an academic information resource for students. The center 
maintains up-to-date records of all students in the college, provides information 
on its academic programs, and distributes administrative forms for adding and 
dropping classes or changing a major. Every center maintains computer access 
to a variety of student information, including new student admissions profiles, 
ACT data, transfer equivalencies, up-to-date academic records, and degree audit 
reports. In general, the CAC is a place where a student can receive on-line 
information from someone who has been trained in the use of advisement data. 

University Advising Core 

The centralized-coordinated/decentralized -operated organization of 
academic advisement in the university, administered by the Office of Academic 
Advisement, ensures a campus-wide quality program, while allowing colleges to 
address the unique advising needs of students. Each CAC provides the following 
standard university advising functions: 

1. Academic advising for the college. CAC personnel, available daily 
between 8:00 a.m. and 5:00 p.m., provide services either by appointment 
or on a drop-in basis. 

2. Advising file. Each CAC has access to on-line student data (ABC 
report, high school data, registration/scheduling screens, transcripts and 
transfers data). 

3. Evaluation of transfer credit. CACs assist in the evaluation of new 
and unique transfer credit from institutions. 

4. New student orientation. Each CAC supervisor plans and coordinates 
the college's new student orientation program in conjunction with the 
overall university program. 

5. Degree profiles. Each CAC maintains and publishes degree 
requirement profiles for each major or emphasis within the college. 

6. Faculty advising. CACs coordinate, with department chairs, the 
assignment of faculty advisors to students. 

7. Registration assistance. CAC personnel provide registration 
assistance and advice to currently enrolled students within their college as 
well as for new incoming students. 

8. Graduation clearance. Working closely with the Office of Graduation 
Evaluation, CACs review all potential candidates for graduation. CAC 
personnel work closely with department chairs to clear a student's 
completion of major requirements. 

9. Referrals and appointments. Since some student questions are not 
addressable by a CAC and CAC personnel are familiar with other campus 
services, they often collaborate with other faculty or simply refer the 
student to the appropriate service. 
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10. Academic assistance seminars. CACs coordinate a variety of 
seminars relative to the interest and academic needs of the students and the 
college. 

In summary, CACs provide personalized advising services by helping 
students plan thfeir educational program consistent with their interests, abilities, 
and academic goals. To accomplish this end, advisement centers provide an 
advisement core that offers a wide range of services to students. 

THE FIRST YEAR EXPERIMENT 

After incorporating the features of student academic information of TTT, 
ABC, and CACs, our aim became twofold: (1) provide students better and timely 
access to their individual record and (2) refi;^ or make more user-friendly existing 
TP prograrns-primarily those used by faculty and staff-for student use. We 
selected five of eleven college advisement centers to participate in the experiment. 

On a weekly basis for a semester, our computer programmer and 
Registrar and Director of Registration met with personnel in the CACs to (1) 
devise ways and means to study the affects of the AIM program, (2) resolve 
hardware and software (remote access) matters, (3) discuss security measures, (4) 
refine current academic information TP screens to make them relevant and useable 
AIM menu items, (5) decide where AIM terminals should be located, and (6) 
strategize our communication to students and faculty about the availability of the 
AIM system in the five experimental stations. These meetings laid the 
groundwork for the following materials and programs used in the experiment: 
The Academic Information Management Questionnaire , Users Guide , and AIM 
Flyer and Poster (see Figures 1-3). 

THE SECOND YEAR EXPERIMENT 

Based on the very positive results obtained from advisors and students who 
used AIM during the second semester of the first year experiment, several changes 
were implemented during the second year. First, many of the menu items were 
either enhanced or rewritten while other items were added (e.g., transfer work 
and grades). Second, we eliminated the User Directory . Due to changes and 
enhancements in programming, we were able to cross-reference many of the items 
in the Directory . In all other cases, we simply included instructions as a "help" 
screen for each menu item. In other words, we made AIM a navigable program 
by simplifying, cross-referencing, and integrating most of its features. Third, 
expanded options and success forced us to expand AIM locations. AIM is now 
available in several on-campus housing areas, all advisement centers, the student 
union building, and in counseling and development offices. 
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THE AIM PROGRAM AND CURRENT FEATURES 



The overall purpose of AIM is to help students answer minor questions 
about their academic progress. AIM answers a variety of students' academic 
progress questions, when students need answers. It provides timely and convenient 
access to important and individual academic information. As discussed above, 
ABC reports and TTT are good technologies but are not sufficient especially for 
a dynamic, multiple-optioned and complex environment of delivering student 
academic data to the campus community. The trend in technology seems very 
much to be one of optimizing user and machine interface. For example, the TTT 
cannot effectively allow users to register by need or interest. It simply would take 
too much time or be extremely cumbersome. Yet by interacting with AIM menu 
items, a user can enroll in courses by instructor or requirement deficiency. If 
a course is full for the upcoming semester, the user can identify when the course 
will be taught in the academic year or when the desired instructor will teach the 
needed course again. In fact, by using AIM, the user can register six different 
ways by using the following menu items: (1) academic progress for major 
requirements, (2) instructor teaching schedules, (3) the class schedule-locating 
specific classes by time or searching the current class schedule, (4) major 
shopping, (5) general education progress, and (6) direct registration screen 
(similar to TTT). 

AIM provides the user with a visual exploration of and dynamic interaction 
with the university's student information system. Once the user's social security 
number and personal identification number are entered, an array of information 
services becomes available. Users can concentrate on academic records with 
AIM. Students can call up their current academic record instantly. Menu options 
include the following: 



* address and phone changes 

* the university and personal class schedule by semester or term 

* course availability for the academic year 

* general education and major progress (ABC) 

* grades and BYU credit earned 

* instructor schedules 

* options within a major (shopping for a major interactively and 
dynamically) 

* PIN changes and registration 

* transfer and AP credit/grades 

* individual demographic information 



Simply put, AIM takes the pressure off advisement centers and faculty 
members who used to have to repeat mundane and routine data for students. 
Suk *nts can access the data themselves and then seek for advice from 
professional staff and faculty members. 
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THE FUTURE OF AIM 



Like all technical programs designed to serve the academic community, 
they quickly become outdated with emerging technology. The computer 
environment clearly continues to change the way we think about and do our work. 
AIM is no exception to the computer revolution. It's a composite as well as a by- 
product of past efforts. Although AIM is not a finished concept, it is nevertheless 
an attempt to capitalize on the computer industry's direction in distributing 
information to others. As hardware and software become more sophisticated, 
paralleled by significant costs in the industry, institutions in general and AIM 
specifically will continue to be challenged to incorporate new technological 
advances. 

What's on the horizon for AIM? We see at least three hopes for the 
future. First, we hope that AIM can be expanded to off-campus users via modem. 
Like the TTT of the 1980s, computers with a modem punctuate the homes of the 
1990s. We envision soon the opportunity for students via their personal computer 
(with modem), to gain access to the current services of AIM. Certain obvious 
security measures create a disadvantage here, since current access to AIM is 
through a mainframe environment. Much of this concern, however, will be 
resolved through a distributive or open computer system. 

Second, we hope soon to include access to AIM for transfer students from 
major feeder schools. Ethernet is the key link here. At present, we can transmit 
both admission data and historical records wholesale from these schools. Since 
this work is going well, we hope soon to provide individual access to AIM to 
feeder schools. 

Finally, we hope not only to expand the number of AIM terminals on 
campus, but also to substantially increase access to other information needs of the 
campus community. For example, it is our intent to expand AIM to all campus 
living units as well as to the library and other key places on campus. Expansion 
of AIM's menu in the future will most likely include (1) Cooperative Education 
locations and contacts; (2) Career Planning and Placement services, such as an 
announcement for registration of campus visits by prospective employers; (3) 
daily, weekly, and monthly campus events; and (4) university deadlines such as 
drop/add, graduation application, and tuition payment. Within this environment, 
it is hoped to electronically create mailboxes for students and faculty alike. For 
example, we could potentially eliminate the costly distribution of ABC reports by 
promoting the use of AIM's menu on academic progress information. Other 
information items that could be passed electronically to student mailboxes include 
notifying students of academic "holds" in the university or a message to apply for 
graduation. 
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CONCLUSION 

Dreams are simply goals with deadlines. Who knows our limits? Perhaps 
it is time to try something new and take a chance. Although most institutional 
student records management or student information systems are running smoothly, 
Burt Nanus observed that leadership in any field is really all about fixing things 
that aren't broken! So perhaps it's appropriate to ask "What's next, and why?" 
AIM has stimulated our imagination; the possibilities may be nearly endless. 
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Academic Information Management 



Appendix A 



QUESTIONNAIRE 
Help! 

Please help us to refine this program by answering the following 
questions. Circle your answers. 

Disagree Agree 

1. I didn't have any problems using the 1 2 3 4 5 
system, 

2. Written instructions were clear and easy 1 2 3 4 5 
to understand. 

3. Written instructions were helpful in 1 2 3 4 5 
guiding me from one screen to another. 

4. The menu titles were an accurate 1 2 3 4 5 
description of the information in that 

category. 

5. I was able to understand the 1 2 3 4 5 
information displayed on the screens. 

6. The menu gave me access to all the 1 2 3 4 5 
information I wanted. 

7. I am confident the computer has 1 2 3 4 5 
correctly recorded all my update 

changes. 

8. I would use the system again. 1 2 3 4 5 
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I used these I printed 
screens: these screens: 



Address/Phone Change 


□ 


□ 


Class Schedule 


□ 


□ 


Course Availability 


□ 


□ 


Grades and BYU Credit 


□ 


n 


GE Progress (ABC) 


□ 


□ 


Individual Information (Biographical) 


□ 


□ 


Major Progress (ABC) 


□ 


□ 


Major Shopping 


□ 


□ 


PIN Change 


□ 


□ 


Registration 


□ 


□ 


Transfer and AP Credit/ Grades 


□ 


□ 



Note: If you experienced any problems or frustrations, or if there is 
information you would like added to the menu, please comment. 
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Academic Information Management 
OPERATOR'S MANUAL 



Appendix B 



Welcome 
to the 
ACADEMIC 
INFORMATION 
MANAGEMENT 
Program 
(AIM) 

Instructions 

Please follow the steps below in sequence. If you get stuck, ask 
advisement center personnel for help. 

1. Type your BYU ID (usually your social security number). 

2. Type your personal identification number (PIN) and press 
©BED. 

Your PIN is the same as that used for Tbuch-tone registration. 

Please feel free to change your PIN at least annually. For 
instructions see menu item 9. 

After use, be sure you exit the system property to maintain 
the confidentiality of your records* 
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MENU 



1. Address/Phone Change 

2. Class Schedule 

3. Course Availability 

4. Grades and BYU Credit 

5. GE Progress (ABC) 

6. Individual Information (Biographical, etc.) 

7. Major Progress (ABC) 

8. Major Shopping 

9. PIN Change 

10. Registration 

11. Transfer and AP Credit/Grades 

12. Exit 
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Students in your 
college can now call up 
their current academic 
records instantly AIM 
(Academic Information 
Management), an exciting 
new software system 
sponsored by Academic 
Advisement, allows 
students instant access 
to such informution as — 



• ADDRESS AND PHONE CHANGES 

• APPLYING FOR GRADUATION 

• CLASS SCHEDULES 

• COURSE AVAILABILITIES 

• GE AND MAJOR PROGRESS (ABC) 

• GRADES AND BYU CREDIT 

• INSTRUCTOR SCHEDULES 

• MAJOR AND MINOR OPTIONS 

• PIN CHANGES 

• REGISTRATION 

• TRANSFER AND AP CREDIT/GRADES 



Designated AIM computers are in your college advisement center, in 
on-campus housing, and at *he ELWC Informatics* Desk. Encourage 
your students to use th.^m to check their records, update them, get 
print-outs, and weigh al> smatives— without waiting. AIM FOR SUCCESS. 

ON-CAMPUS HOUSING LOCATION' (I) MORRIS CENTER COMPUTE U LAI, «) CANNON CIMTIR 
CENTRAL LOR1Y, (3) HERITAGE HALL& ANTRAL WILDING lOilV. AND (4) WMOUNT COMPUTER Ui. 
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New Technology Drives New Technology! 
(In Housing and Food Services) 

Donna F. Young 
Senior Systems Analyst 

Purdue University 
401 South Grant Street 
West Lafayette, IN 47907 

(317) 494-6116 
d f young § adpc • purdue ♦ edu 



In the information systems business we seldom 
spend a single day without learning about the "latest" 
technological advances in hardware and software to 
enhance or build computerized systems. Already this 
month the newer and better is being replaced by the 
newest and best! There are numerous paths that we can 
follow. As the visual portrays, we can barely see the 
forest for the trees (new technology) let alone the 
right path to follow! 

Often when computerization experts experience new 
technology overload, their tendency is to lean on the 
familiar - the tried and true. The same may be said of 
their clients who often follow their lead. Of course 
there are some who "strike out" on their own path! 

Just as change for the sake of change is not 
always advantageous, new technology for the sake of new 
technology is not always beneficial. On a positive 
note, it appears the trend today is toward new 
technology driving new technology . This gives clients 
the option to pick and choose at will to suit their 
business needs. Change no longer need be viewed as a 
byproduct of new technology. 

For this presentation, let's examine what happened 
at one public university during the 1980 's and early 
1990 's as technology relentlessly advanced. At the 
West Lafayette, Indiana campus of Purdue University, 
the Administrative Data Processing Center (ADPC) 
develops and maintains a variety of systems, most of 
which run on the mainframe. These systems support the 
departments who run the business of the university. 
Among these departments are admissions, collections, 
continuing education, housing and food service, food 
stores, and registrar. These business areas are 
diverse yet all connected by the customer they 
ultimately serve. 



During this presentation, we will be considering 
the Housing Accommodations Management and Dining 
Service Management department. While customer refers 
to the customer of the university which is most likely 
the student, the department is referred to as the 
client of ADPC. The visual aids used are not included 
in the proceedings; most visual aids are included in 
the presentation, and a few (such as forms and 
reference guides) are available for review following 
the presentation. 

In the early 80 's, ADPC (and some of its clients) 
often tried to drive new technology by business needs. 
For instance, the data entry area for many of the 
departments at Purdue University resided within ADPC. 
This was moved to the "point of entry" or the business 
area in the university to better service the customer. 
To do so, necessary technology had to be made 
available. In the client area, that technology 
consisted of a "dumb" terminal attached to a telephone 
cable. The data resided in a repository for overnight 
processing. These customer data entry systems had 
online inquiry but not update. Not so much later, 
university business demanded real time inquiry and 
update to satisfy the need for up-to-date information, 
and the client soon began requesting access to data for 
their reporting needs. Various methods for accessing 
the data for reporting were tried. Many failed while 
most required the use of "sneaker net" or carrying the 
data from ADPC to the department on a floppy diskette. 
The business was trying and, for the most part, failing 
to drive technology. 

Not much later, when the Personal Computer (PC) 
arrived on the scene, many felt the inclination to 
allow new technology to "set the stage" for business 
based on what the PC software and hardware could 
provide. To some degree this succeeded as PC memory, 
printers, and software capabilites satisfied some needs 
of the business area. Many PC based systems were 
developed and implemented in the client areas by their 
own computerization experts. A variety of "homespun" 
systems came into being, most without documentation 
when the creator left the scene. Furthermore, the 
operation of each client was often limited to the type 
of technology being used. Since this technology was 
changing rapidly, these clients were also faced with 
the challenge of integrating the new and old 
technology. Some attempt was made by ADPC to 

standardize the purchase of software and hardware. 
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Many university departments were cautious during 
this time — which happened to be to their advantage. 
An example was the business office for Housing 
Accommodations Management and Dining Service Management 
for the undergraduate residence halls and graduate 
houses. They carefully considered the new technology 
and decided to gradually replace the "dumb" terminals 
with PCs. At the same time, some "in house" PC systems 
were developed and/or maintained by their own 
computerization support staff. While this occurred, 
the plan for a university-wide fiberoptics backbone was 
being proposed. (The telephone cables became obsolete 
that day!) Nevertheless, in the business offices for 
Housing Accommodations Management and Dining Service 
Management, it was business as usual. No attempt was 
made to disrupt a successful business operation because 
of new technology. 

Still, the Dining Service Management business 
office had recognized the need for a multifunctional 
computerized system. After careful consideration of 
their needs and what packages could offer, they 
proceeded with plans to have ADPC develop and install a 
fully, automated food service system with planning 
menus, recipes which included food preparation 
instructions, food ordering, and food inventory for use 
by the undergraduate residence halls. This Food 
Service Management Information System (FSMIS) was 
installed to service the client areas daily (24 hours a 
day) in the foods offices of the undergraduate 
residence halls, at the business office for Dining 
Service Management, and in the food stores office. In 
this instance, the technology was used appropriately 
and successfully to meet a business need. 

With this success story to build upon, the natural 
next step was to direct attention to the Housing 
Accommodations Management business office. There the 
processing of new undergraduate applications, housing 
agreements, and subsequent hall assignments to the 
twelve undergraduate residence halls at Purdue had been 
done manually for many years. 

In one year's time that office sends out over 
20,000 application packets to newly admitted students 
who have expressed an interest in university housing. 
There was a growing need to expedite the processing of 
returned applications and, at the same time, continue 
to personalize the correspondence for prospective 
residents. This is just one way of making certain all 
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those interested in undergraduate housing at Purdue 
University receive information promptly and correctly. 
This becomes even more important if the enrollment 
starts to decline as predicted due to the decreasing 
number of high school graduates. 

Normal enrollment at Purdue University is around 
32,000; the undergraduate residence halls house nearly 
10 , 000 of these students , mostly freshmen. Since this 
is almost a third of the student population, even if 
enrollment dropped 1,000 that could mean as much as 300 
vacancies in the undergraduate residence halls! Some 
right moves must be made to attract not only new 
residents but retain the current resident population. 

Right moves meant maintaining the competitive 
edge, but as David Bridgeman, manager of Competitor 
Analysis at British Petroleum (BP) corporate center in 
Cleveland states , "Competitive analysis is thinking 
about external forces over which you have little, if 
any, influence. In a way, it complements economic 
analysis. We can attempt to understand how external 
forces [declining enrollment and housing costs] affect 
us and take steps to optimize our performance given the 
possibilities. The same holds for competitor actions 
and reactions. But we need to strike a balance between 
being too inwardly focused and too externally 
oriented. 11 * The director for Housing Accommodations 
Management decided to "take steps to optimize our 
performance given the possibilities" by asking some 
important questions. 

How best could students be attracted and retained 
in the residence halls? Already the food service 
provided was excellent with the recently added 
attraction of meal plans. Student computer labs were 
being placed in each undergraduate residence hall and a 
new hall was being built to replace an outdated hall. 
Was there a solution in new technology being made 
available to the university? 

Coincidental ly , these questions occurred at the 
same time that the fiberoptics backbone proposal was 
being approved. Technology would soon be available to 
provide the needed access to data. The business office 
of Housing Accommodations Management could "track" 
information about prospective residents as they were 
given housing accommodations information and produce 
correspondence quickly from downloaded student 
information. This could allow the office to provide 



(and record) a personal response to individual requests 
much more quickly. 

The idea for a Purdue Resident Information Data 
Exchange (PRIDE) system was conceived! Its central 
purpose was to track the prospective resident from the 
time the student was admitted to the university until 
actually completing a housing application, signing an 
agreement, and being assigned to a hall. The business 
office of Housing Accommodations Management wanted to 
analyze how best to meet the needs of the prospective 
resident population. Building on this information, the 
needs of the current resident population in the 
undergraduate residence halls and the graduate houses 
could also be considered. 

The whole process begins when the prospective 
resident contacts the university admissions office 
about being admitted. Upon admission, the business 
office of Housing Accommodations Management is 
notified. They respond by sending a packet of 
university housing accommodations information to the 
prospective resident. PRIDE is first initiated by 
entering the student id into the system. This 
indicates that a packet will be mailed to the 
prospective resident. Counts are kept for future 
analysis of both male and female students who have been 
sent a packet. These counts are available both online 
and in a weekly report. 

As applications are returned, they are keyed into 
the system along with specific attributes about the 
applicant to indicate the type of correspondence to 
produce. For instance, if an applicant indicates a 
physical limitation or dietary concern, these 
attributes are selected and paragraph codes downloaded 
(along with the student information) to be used to 
indicate specific paragraphs to print in a personalized 
letter to the applicant. Again, counts are kept of 
attributes and completed applications for both male and 
female applicants. Forms are generated such as a cash 
receipt voucher which is sent to the collections office 
with the deposits received for applications and labels 
for each housing applicant. 

All correspondence and some forms are printed in 
the business office of Housing Accommodations 
Management while large batches of agreements and weekly 
reports are produced at ADPC. A new laser printer was 
purchased for use by ADPC to replace many of the green 
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bar reports and many of the cumbersome and expensive 
multipart forms used by the clients , One such three 
part form was the housing agreement. The business 
office of Housing Accommodations Management became 
enthused about creating a new agreement on the laser. 
With assistance from ADPC technicians, they have 
developed five different agreement forms to be produced 
on the laser. This saves time and money while 
providing a better service to the customer — the 
student! (Part of the savings was realized by 
utilizing a software package for verifying mailing 
addresses and obtaining zip+4 codes.) In the near 
future, we hope to also utilize the bar codes provided 
by this same software package and additional savings 
from yet another software package for mailing the 
agreements . 

The returned agreements are entered into the 
system, along with the hall preferences and roommate 
requests. Mutual roommates are recorded. A priority 
date is assigned by the system and when the hall 
assignment batch process is complete, all 6,000 new 
undergraduate students are assigned to a preferred 
residence hall based on a priority date, roommate 
requests, and available space. This has greatly 
enhanced not only the agreement entry process but also 
the hall assignment process. Hall assignment 

statistics show that the majority of applicants do 
receive their first hall preference. Furthermore, it 
takes just hours rather than days to provide these 
assignments to the halls. 

This completed the first phase of PRIDE with the 
exception of the installation of fiber which required 
that we change from one software package to another to 
complete the download of information for printing 
correspondence and forms. 

Once the applicant is assigned to a residence hall 
or graduate house, they are considered a resident and 
as such, become the responsibility of the residence 
hall or graduate house. 

As we took the next step to develop the remaining 
pieces of PRIDE for the undergraduate residence halls 
such as room assignment, cancellation, reapplication, 
room changes and so on, two residence halls became 
pilot or test sites. These two pilot residence halls 
were outfitted with the necessary hardware and software 
to try processes in PRIDE before being used by all 




undergraduate residence halls. 



To conduct a successful pilot, the two halls were 
required to kec^ their current PC based system updated 
along with the new PRIDE system. Although the 
residence halls do not produce the abundant 
correspondence that the Housing Accommodations 
Management business office does, they have an abundance 
of reports and forms such as the reapplication 
agreement, alpha directory, floorchart, meal plan list, 
notice of assignment, and vacancy, to name just a few. 
They also needed the capability of using downloaded 
resident data to print reports and forms in the 
residence hall rather than offsite. 

As a pilot test of the File Transfer Protocal 
(FTP) software which was to be used with the fiber to 
download or upload data, the two pilot undergraduate 
residence halls were given access to the ADPC file 
server and by using FTP could obtain resident data for 
reports and forms. Based on some change just completed 
such as a room change, or for general information 
reports, data is requested online. This online process 
submits a batch job to the internal reader at ADPC to 
produce an extract reporting file which is then placed 
on the ADPC file server. The client signs into FTP and 
requests the information (based on the needed report or 
form) to be downloaded to the PC at their workstation. 
Using Microsoft Word or Dbase, the report or form is 
produced. Without the fiber, this process is slow; 
with the fiber, it is a completely different story! 
Good-bye "sneaker net" and hello fiberoptics! 

We were aware that most of the undergraduate 
residence halls had only one PC available in the foods 
office and in the main business office to service a 
staff of 4-6 in each. To use the capabilities of the 
new PRIDE system and the fiberoptics technology, newer 
hardware and more of it was needed. The division of 
Housing and Food Services made a rather large 
acquisition of 96 new PCs to be installed in the 
business office of Housing Accommodations Management 
and Dining Service Management as well as in the 
undergraduate residence halls and the graduate houses. 

Plans were made to follow the fiberoptics 
installation into the undergraduate residence halls 
with the new hardware and the new PRIDE system. This 
meant that after physical facilities staff installed 
the wiring in the residence hall, the network staff 
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"lit" the fiber, and ADPC staff connected the fiber to 
the PCs . It also meant that a standard conf igurat ion 
on all PCs must be installed before being connected to 
the fiber. 

Over half of the office staff had never had a PC 
at their workstation. This meant that ADPC somehow had 
to assess the PC training needs. A PC Skills Self- 
Appraisal was developed, and a copy (with instructions) 
was sent on diskette to each staff member. In this 
way, they could assess their own training needs for the 
PC, and then sign up for classes given by ADPC. The 
residence hall staff also needed training to understand 
what standard configuration meant, how to access FTP, 
and how to use the new PRIDE system! 

A plan was devised to give each undergraduate 
residence hall a week during the summer of 1992 to 
receive new equipment, have it connected to the fiber, 
have the current data converted for use by PRIDE, and 
be trained to understand standard configuration and how 
to use PRIDE and FTP. 

Fiber installation was slowed down by the fact 
that only one person was allowed to " 1 ight it . " We 
fell short of the installation goal by two residence 
halls. Six residence halls had complete fiber 
connection, four had the connection via one PC, and two 
residence halls had the telephone cable access again 
requiring that two systems be kept in sync . It is 
gratifying to say that those residence halls with fiber 
were completely happy and became busy trying new ideas 
themselves for reports and forms as well as business 
processes! Those who had to wait longer to download 
the data or worse still, use "sneaker net" were not so 
happy. The good news is, they did not have to wait 
very long! By the second semester of the 1992 academic 
year, all undergraduate residence halls , the graduate 
houses, and the business office of Housing 
Accommodations Management and Dining Service Management 
had access to the fiber. 

With the advent of fiber, every PC regardless of 
location is given access to the mainframe at ADPC. 
This provides access to the FSMIS system, the PRIDE 
system, the collections system, the registrar system, 
the stores requisition system, and other mainframe 
systems from any PC! Because of twofold security, only 
those who have access to the FSMIS or PRIDE system 
(files and processes) based on their security profile, 




can update information for their residents and can 
inquire about all residents in the undergraduate 
residence halls - past, present, and future! 

Training is always the mountain to climb • 
Fortunately, new technology has also provided the means 
to train effectively! The training area at ADPC 
continues to be utilized for classes about new phases 
of PRIDE as well as courses in PC skills, FTP and 
standard configuration. Each residence hall has a "key 
user 11 who can support and train other residence hall 
staff which provides for transfer of knowledge and job 
satisfaction. 

To accompany the training, reference guides were 
developed, one for the FTP software and one for the new 
PRIDE system. Each time a large process is completed 
for use by the residence halls, hands-on training is 
provided. The PRIDE Reference Guide is also updated as 
new processes are introduced or as new business areas 
are added to the system. 

Reviews of the major processes are conducted as 
they are completed; based on the business needs, 
requests for enhancements are made and prioritized. 
This rework to the PRIDE system is scheduled to be 
undertaken when there is a lull in development of the 
next subsystem or phase. 

By the fall of 1993, the graduate houses also hope 
to be using PRIDE, and the business office of Housing 
Accommodations Management and Dining Service Management 
hopes to have their own network and file server. This 
will further enhance the communication between the 
undergraduate residence halls, the graduate houses, the 
food stores office, and the business office of Housing 
Accommodations Management and Dining Service Management 
as well as with other university departments outside 
the realm of housing such as continuing education which 
is the registrar for conferences at the university. 

Event Planning and Administration which handles 
conferences at Purdue University is also considering an 
updated computerized system to be used to make housing 
assignments and bill conference attendees. Many 
conferences, both large and small, come to the 
university during the summer, bringing revenue to the 
university and the community. An August 3 , 1992 
article by Joe Gerrety in a local newspaper (Lafayette 
Journal & Courier) addressed that subject and stated: 
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The conference (Methodist Men) has a budget of about 
$1 million, and James Snead, one of its organizers in 
Nashville, Tenn., said about 7,000 men are expected to 
attend the next conference in 1993. By the time they 
leave, they will have spent about $1.5 million, Snead 
estimates. The conferences (at the university) attract 
85,000 people for an average stay of two days, according 
to Gary Lee, associate director of conferences. Lee said a 
fiscal impact study conducted nine years ?go determined 
that Purdue conferences pumped $25 million to $30 
million a year into the Greater Lafayette economy. 

Beyond 1993, computerization plans include (in 
particular) interfaces to FSMIS and PRIDE, and (in 
general) whatever else may be needed for these areas to 
operate effectively in the 21st century in this giant 
chess game! 

As William Hartston, an international chess master 
stated, "There are some easy ways to lose a chess game: 
first, do something when you shoulu be doing nothing; 
and second, do nothing when you should be doing 
something. Everything depends on how well placed the 
opponent is to counter what you are trying to do, and 
to launch a successful aggressive action of his own. 
Two other easy ways to lose a chess game are to plow 
ahead with your strategy, regardless of what the 
opponent is doing, or to have no strategy other than to 
avoid mistakes."* 

What is the best stategy? Most computerization 
experts believed just a decade ago that the business 
would be changing because of new technology. Today we 
see the public university's business changing more 
because of the customer or competition. For most, it 
is important to concentrate on the business at hand. 
For, as Mr. Bridgeman of BP stated, "Business books are 
filled with examples of how companies thrived or 
suffered depending on how much attention they spent on 
the customer and the competition."* In the meantime, a 
successful computerization effort can be achieved by 
the use of new technology as it becomes available, to 
not fear it or change just for it, and to always affect 
quality not quantity. in essence, allow new technology 
to drive new technology! 



"Shield. The International Magazine of the BP Group, U.S. Edition. 
Cleveland, Ohio. Summer 1992. 
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The University 

The University of Wisconsin-Madison was founded as a land grant institution in 
1849. As the flagship of the University of Wisconsin System, it has consistently ranked 
in the top 10 universities in America in every survey of scholarly reputation conducted 
since 1910. UW-Madison offers 156 bachelors degree programs, 184 masters degree 
programs, and 125 doctoral and professional degree programs. Graduate study has 
been offered for over a century, and there are now programs in the biological sciences, 
physical sciences, social sciences and interdisciplinary studies. In the 1991-92 degree 
granting year, 680 PhD degrees and 1,981 Master's degrees were reported. 

The University maintains extensive research facilities, some of which are ad- 
ministered by the Graduate School. These facilities support the research of students 
and faculty beyond their principal disciplines and provide broad public service. 

UW-Madison has total enrollment of 41,948 students, including 27,464 under- 
graduates, 10,414 graduates, 1,836 professionals, and 2,234 special students. The FTE 
enrollment is 37,313. 

Efforts to reduce enrollment at the University in the past five years have been suc- 
cessful. Although the number of graduate students has steadily increased, the number 
of degrees granted has remained constant. For the first time in history, the Graduate 
School is facing enrollment management. 

Administrative Data Processing (ADP), a part of the University's Division of Infor- 
mation Technolgy, is the main provider of computing support for administrative func- 
tions for UW-Madison. One of its major roles is to support the Integrated Student Data 
System. ADP and the Graduate School designed the Graduate Academic Student 
Progress system to help manage graduate enrollment. 

Background 

The Graduate Academic Satisfactory Progress (GASP) system replaced the old 
Grad School Degree reporting system, which was designed to meet quickly the immedi- 
ate needs of the Graduate School, The system was developed using a software package 
developed internally. Information for Master's and PhD degrees not entered using that 
transaction was kept on a card system and within the individual graduate student's 
paper files. Space constraints and the need to better serve grad students and depart- 
ments prompted the Graduate School to move to a paperless recordkeeping system. 



SystG j Description 



1 ae GASP system enables Graduate School staff at the University of Wisconsin- 
Madison to track degree* and satisfactory progress. GASP integrates information 
formerly maintained on paper and on the mainframe computer. Graduate School staff 
can review each student ?, status online. Eventually, graduate departments/programs 
will be able to review and enter online data that is now provided on paper to the 
Gradi late Sch ool, 

ITie GASP system has six parts: Degrees, Prelims and Other Requirements, 
Grades, Change/Add Major, Information for Departments and Students, and Degree 
Committees and Minors. 

Degrees 

The degree tracking component of the GASP System replaced the system of 
reporting graduate degrees to the Registrar's Degree Summaries Office and al- 
lowed the Graduate School to phase out an old degree card file system. Benefits of 
the degree tracking component of GASP include: 

1) Discontinued the batch job that produced master's degree cards and totally 

eliminated the master's and PhD card file and the need to manually type 
and file each card after a degree has been granted; 

2) Ended the need to proof warrants against degree cards; 

3) Will automate the production of documents and reports formerly generated 

as word processing documents or by hand: 

• master's, prelim, and final PhD warrants; 

• follow-up letters to students who have not completed degree require- 
ments; 

• letters/reports to departments indicating student degree status; 

• reports to the Registrar regarding cooperative degree students from 
UW- Whitewater or U W-Oshkosh; 

• reports to the Registrar listing students who have changed or added a 
major. 

4) Will eliminate the need for the Registrar to re-key degree information and 

therefore allow for a more timely and accurate posting of graduate degrees. 
An edit system is now being developed to eliminate common keying errors. 

Prelims and Other Requirements 

GASP provides teleprocessing screens to record PhD preliminary exams, the 
completion of major and minor requirements, and the completion of the Graduate 
School residence requirement. The residence requirement is calculated by hand 
each semester depending on satisfactory completion of current course work. GASP 
will be used for information that is now input via the Grad Student Info Change 
transaction. Additional data, now stored on the PhD cards, will also be input via 
GASP. Thus departments will be able to view information once available only on 
cards. 
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Benefits of this component are: 

1) Will produce automated dissertator letters thereby eliminating the need to 

manually affix labels to letter(s); 

2) Will make possible timely feedback to students and departments about disser- 

tator eligibility; 

3) Will reduce phone calls and foot traffic at the Graduate School; 

4) Will provide up-to-date information about residence for students and depart- 

ments; 

5) Will assure students that they are not short of residence at the dissertator 

stage or for master's degrees; 

6) Will produce a report for departments listing PhD candidates who were 

within one year of the "defend within five years of passing prelims" require- 
ment. This department report also lists the student's thesis advisor and 
reminds the department and student of the five-year rule. 

Grades 

GASP automates the identification and monitoring of students with GPA 
problems and Incomplete/Progress/Not Reported grades. This information was 
formerly calculated manually and recorded on paper in student files after staff 
reviewed semesterly reports. The system now interacts with the Registrar's student 
data files to calculate the Grad School GPA and to monitor Incomplete/Progress/ 
Not Reported grades. A planned enhancement will generate a list of cleared Incom- 
plete grades and the effect on the student's GPA and degree status. 

The benefits of this component include: 

1) Will gready reduce the time needed for Graduate School staff to review a 

student's records; 

2) Will inform students and departments more quickly of Graduate School warn- 

ings, probations, or drop actions; 

3) Will generate a weekly report of degrees that were held because of grades 

and will indicate when the grade has been cleared; 

4) Will generate for departments a list of courses taken outside the department 

with Incompletes. 

Change/Add Majors 

GASP automates the change/add major process. This process involves an ap- 
plication and an admission decision. This information was stored in the student 
paper files, and only a positive decision to either change or add a major was 
reported to the Registrar via a paper form. Graduate School staff now enter the 
decision into GASP and may request an automated list. 

The primary benefit of this component is that it allows the Graduate School to 
know the number of change/add requests and track them in the admission process. 
Ultimately, it will provide additional information for the "time to degree." 
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Information for Departments and Students 

After a future enhancement, an inquiry transaction will enable depart- 
ments/programs to gain access to certain fields on GASP. Some of this information 
may eventually be available to students via a current transaction called Extended Ac- 
cess to Student information (EASI). 

Benefits of this component include: 

1) Will reduce the number of phone calls and foot traffic to the degree offices, 

especially at peak periods in the degree-granting process; 

2) Will provide immediate feedback about such items as: cumulative weeks of 

residence earned to date, whether a student has been certified for disser- 
tator status, and whether the warrant was issued. 

Degree Committees and Minors 

Allowing departments to update certain fields on GASP will help them monitor 
the degree committees and the minor agreement approval process. This enhance- 
ment will eventually help track departmental criteria for satisfactory progress. 

Benefits of this component include: 

1) Will eliminate forms now submitted by departments to record the minor ap- 

proval ar. ." "le final oral committees; GASP will check faculty eligibility and 
monitor tne PhD minor requirements; 

2) Will produce departmental reports listing faculty advisor/dissertation chair, 

time to achieve dissertator status, and time to degree tied to student employ- 
ment history; 

3) Will help departments track faculty responsibilities for graduate students. 

System Design 

GASP was implemented on an IBM mainframe computer. The system takes ad- 
vantage of the strengths of COBOL II and DABAL IV (a report writing language 
developed in house) for the programming languages. The teleprocessing monitor is 
IMS. The information repository is DB2, an IBM relational database system. 

Database Design 

An important reference in defining the database's entities was Entity Modeling: Tech- 
niques and Application by Ronald G. Ross. The eight entities defined by the process are: 

Student 

Student, for GASP purposes, is the collection of existing Registrar student files. 
These IMS files are the repository for core student data of interest to the entire cam- 
pus. Included in Student are student name, date of birth, address information, clas- 
sification, year in school, course registrations, and other transcript information. 

Degree Tracked 

Degree Tracked is the kernel entity for the degree tracking system. The primary 
key is degree number (a system-assigned number.) Student ID is carried as a 
foreign key to provide access to the student's other campus records. A grad student 
will have one record for each degree attempted. The record contains information 
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specific to the degree being tracked. This includes degree code, degree expected, 
conferred, and reported terms, exam dates, thesis deposit date, etc. 

Degree Major 

A degree may be granted for eidier a specific major or a joint major. Additionally, 
at the PhD level, the degree may be for a specific option within the major(s). This 
table holds the major code, option, and major completed date. It is keyed by degree 
number concatenated with a sequence number, allowing for storage of the joint 
majors (current business rules allow up to four majors). 

Degree Minor 

PhD degrees may have an associated minor and option. The minor table is keyed by 
degree number concatenated with a sequence number. The business rules call for 
storage of up to four minors. This table stores the minor code, option, minor ex- 
pected, and actual completion terms, departmental sign-off indicator, and 
departmental approval date. 

Degree Committee 

PhD committees must have a minimum of five graduate faculty and a maximum of 
six. Master of Fine Arts committees must have a minimum of four and a maximum 
of five, and master's committees a minimum of three and a maximum of five. 
Graduate faculty includes all tenure-track faculty holding professorial (full, as- 
sociate, or assistant) rank in any department with graduate program authority, in- 
cluding those faculty with zero-time appointments, and who are eligible to serve as 
a major professor and serve on doctoral and master's examination committees. 

The key for this table is degree number concatenated with a sequence number. This 
table currently contains the committee member's name and the department he or 
she represents. A future enhancement will provide an interface to the University's 
appointment system. This will eliminate the need for the Graduate School to enter 
and store committee member name; instead, only the primary key of the appoint- 
ment system will be maintained. 

Problem Course 

Grades of NR (not reported), PI (permanent incomplete), I (incomplete), and P 
(progress) in courses above the "300 level" are not acceptable for meeting the re- 
quirements of graduate-level degrees. Also, at the PhD level, grades of F (failure) 
and U (unsatisfactory) are not acceptable. The list of courses with unacceptable 
grades is compiled from the student's transcript files for display on GASP. The Prob- 
lem course table is used at the master's level to indicate either: 1) Grad School has 
approved the course grade, or 2) die student is also pursuing a PhD degree and 
this course work is to be applied toward the PhD degree, not the master's degree. 
The Problem course table is keyed by student ID concatenated with a sequence 
number. Up to six course numbers, terms of enrollment, and PhD/Grad school ap- 
proval indicators are allowed. 

Degree Prelims Ext 

A candidate for the PhD who fails to take the final oral examination within five 
years after passing the preliminary examination is required to take another prelimi- 




75 — 



nary examination and be admitted to candidacy for a second time. This table 
records exceptions to this rule. Up to three prelim extension dates may be granted. 

Degree Thesis Title 

This table holds the free-form title of the PhD thesis. Up to eight lines of 78 charac- 
ters each can be displayed. The thesis must be the candidate's own work. It may be 
the result of research enterprises in which others have collaborated; but in such 
cases, the candidate is required to present a substantial portion which represents 
the candidate's own contribution. 



Student 



Problem 
Course 



Degree 
Tracked 
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Entity Relationship Diagram for the GASP System 



GASP System Screen Samples 



Menu and 
Error Screen 




THE GRADUATE SCHOOL 
UNIUERSITY OF WISCOHSIH - MAD ISC; i 



11:06 



STUDENT ID 
STUDENT NAME 
DEGREE LEVEL 
DEGREE CODE 



093 333 3333 
DOUGH. J OHM A 
M 

MS 247 MS-DAIRY SCIEMCE 



1*HELP S«MAJOR 6= DELETE 18 c ADD 11 "EXIT 12-SGRD 



Master Sign-up 
and Clearing 
Screen 



THE GRADUATE SCHOOL 
UNIUERSITY OF WISCONSIN - MAD I SON 



12/16/32 
11:56 



DOUGH* JOHN A 

MS-DAIRY SCIENCE 



H 1 

HS 2-17. 
2 32 



10 12 32 



2-17 



REG ISTERED 



MAJORS 
DAIRY SCIENCE 



333 333 3333 

DEGREE LEVEL 
CODE 

CONFERRED 

SIGNUP DATE 
RESIDENCE REQ 
FEE APPROVED 

DATE PAID 
OVERLAP REQUIRED 

RECEIUED 
DISSERT A TOR 

LETTER REG 
COOP COLLEGE 
WINDOW DEGREE 
WATCH GPA 
SPECIAL STUDENT 



1«HELP 2 "MENU 4-DISR 5=HAJ0R 6«EDIT 7»PREV B^MEXT 3 -SWAP 11-EXIT 12<=SGRD 



GRAD GPA 3.500 

338 I P 



GRADES 
3 32 DY SCI 



Master Warrant 
Screen 



THE GRADUATE SCHOOL 
UNIUERSITV OF WISCONSIN - MAD I SOU 



DOUGH. JOHN A 



12/16/92 
11:03 



M 1 

MS 247_ 
2 92 



MS-DAIRY SCIENCE 



REGISTERED 



MAJORS 
DAIRY SCIENCE 



GASP 
DYS 

333 333 3333 

DEGREE LEVEL 
CODE 

CONFERRED 
REPORTED 

WARRANT REQUEST 
ISSUED 
RTM UNSIGN 

EX AN DATE 

THESIS REQUIRED _ 

DEPOSITED 

CERT REQUESTED _ 

AUTHOR I2ED 

UN IV SPC STDMT 
DEGREE HELD 

THESIS 

GRADE 

1-HELP 2*flEHU 4"DI3R 5*HAJQR 6 "ED IT 7*PREV B B HEXT 3 e SWAP 11 -EXIT 12=SGRD 



COMMITTEE 



REQUIRED 
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Major Changes 
Screen 





(A 



-78' 



CUMREC 

■AYLOH * . 
UNIVHWTY %W 

• . • . • . * 

• •jA' fc - - '- 




(Son Antonio 





INFORMATION 
TECHNOLOGY: 

The Revolution 
Continues 



STUDENT INFORMATION SYSTEMS 

M2-2 

The Registrar Does 
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THE REGISTRAR DOES STRUCTURED QUERY LANGUAGE 
SUBTITLE: THE ERA OF THE AD HOC QUERY HAS ARRIVED 
JUST IN TIME TO HELP THE REGISTRAR 



Ann M. Liska 
Registrar 
Lawrence Technological University 
Southf ield, Michigan 
(313)356-0200 
BITNET AML@LTUVAX 



About five years ago, Lawrence Technological University began work 
on a computerized student records system. For many years, Lawrence 
Tech had used a hard copy record keeping system; permanent record 
cards were maintained for each student, and grade labels were 
pasted on the cards for each term the student attended. Computer 
storage was so limited and expensive that only summary totals were 
kept in computer files. The Registrar's Office was required to 
keep the summaries, which were hard-coded in the files, up to date 
by filling out coding sheets each time a grade change, grade point 
average recalculation, or other change was made to a student's 
record. This system was replaced in 1988 by the Academic 
Information System (AIS). More than 45,000 student transcripts are 
now stored on-line in the AIS data base. 

During the intervening time, the Lawrence Tech disk storage 
capacity on the VAXCLUSTER has been increased to 26 gigabytes. 

A great deal of planning went into the design and implementation of 
the AIS. A consultant from Digital Equipment Corporation spent a 
year on campus working on the design and documentation. The deans 
and directors were interviewed to determine system requirements. 
Weekly meetings of the design team were held. The Registrar, Ann 
Liska, and the Computer Center director, John Grden, worked 
closely on the project and were confident that the new system would 
meet the institution' s requirements . In June of 1988 the 
University printed the last set of permanent record cards, and the 
AIS was put into production in August of 1988. 

The database system used for the AIS is Digital Equipment 
Corporation's VAX Rdb, a relational database. In a relational 
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database, the data appear as a collection of tables. These tables 
can be manipulated to produce desired reports, either through the 
standard AIS interface, through the Relational Database Operator 
(RDO) utility supplied by Digital, or by using Structured Query 
Language (SQL). RDO, although it can be used interactively, is 
mainly designed to be used in programs. SQL is easier to learn and 
can be readily used either interactively or in programs. 



A list of the tables that currently comprise the student database, 
STUDENT_INFO , can be found in Appendix A. 

Each table contains various data elements. Here is the 
information found in the DEGREES table: 



DEGREE_NUMBER 


a unique number assigned 
to each degree program 


DEGREE_CODE 


a two letter code 
representing the degree 
program 


DEGREEJTYPE 


level of degree 


DEGREE_NAME 


name of degree to appear 
on transcripts 


DEGREE_CURRENT 


is degree current - Y/N 


DATE_ADDED 


system date degree was 
added 


ADDEDJBY 


user code of DB 
Administrator who 
added degree 


GRADJDEGREE 


is it a graduate degree 
Y/N 


ADM_DEGREE_CURRENT 


can persons currently be 
admitted to this degree 
program - Y/N 



Table 1 : Degree_granted 



From the perspective of five years into production, it appears that 



we were remarkably accurate in predicting the standard reports that 
would be needed. This is not to say that no problems have 
occurred. The process of "getting off cards" proved painful in 
some ways and some users still print large volumes of hard copy 
reports. With the aid of the Veraldi Center for Educational 
Technology at LTU (our user-services department) we plan to imbue 
those paper-oriented users with the advantages of paper-free 
operations. We also designed some reports that were thought to be 
desirable, but are now rarely used. 

Our most pressing problem became the need for ad hoc reports. 
Since it was impossible to plan for every report that might be 
needed, our initial plan was to have users fill out a form 
requesting the special reports. In fact, a form was designed and 
can still be found in the users' guides, but it has never been 
used. Typically, the need for special reports coincides ^vith a 
vital project such as an accreditation visit, and there is 
insufficient lead time to allow users to fill out a form and wait 
for a response. Our programming and user support team is small for 
a university of our size. Like most other universities in these 
competitive times, we are trying to provide more services with the 
same size staff. It was essential that a way be found to deal with 
the situation. 

The Registrar was concerned about this problem and discussed it 
with the President, Computer Center director John Grden, and the 
Director of the Veraldi Center (LVCET). The LVCET director, 
Professor Thomas Lackey, suggested that SQL could be used to obtain 
the needed reports . 

Another solution would have been to purchase one of the many fourth 
generation language (4GL) products, which allow users to form their 
queries in English-like syntax. The 4GL interface then finds the 
data and returns the results. We have found, though, that by 
having a few individuals use SQL, the majority of user requests can 
be satisfied. More complex reports can be done by the programmers 
as time permits. In our case, also, some of the data resides in 
files that are not part of the student information database. 4GL 
products could not easily find this data. Another important 
consideration was that we already had a site license for VAX SQL, 
so no additional expense, beyond training time, would be required. 

Occasionally, one finds that in using SQL, some queries can take a 
long time. Many factors can be involved in this delay, including 
overall system work load, other users working with the database, 
and SQL's method of forming queries. For example, suppose we 
needed a list of students who attended during a particular term, 
whose cumulative grade point average is 3.5 or above, and who are 
engineering majors. SQL would first find everyone who attended, 
then go through the entire group again to find the gpa, and then a 
third time to find the major. A more efficient way to accomplish 
this might calculate the gpa instead of looking it up, but this 
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still requires a second pass to look up the major, A program can 
be written to find the students and their major and then "save" 
this data so that the second pass looks up only the affected 
students. Whether this is worth doing or not may depend on how 
frequently the report is needed. If it's to be run once a year, it 
may be just as efficient to run the report interactively the one 
time it's needed, and save the programming time for higher priority 
tasks. Alternatively, the report can be done overnight in batch 
mode; the VAXCLUSTER runs through the night but, as would be 
expected, interactive use falls off dramatically at night. 

Here are some examples of reports the Registrar has been able to do 
with occasional assistance from the Veraldi Center and EDCC staff, 

(1) The College of Architecture and Design wanted to analyze the 
performance of their transfer students. The Registrar entered 
the following query in SQL: 



SQL> select studentjnumber , lastjiame, college_code 
cont> from student_prof ile where date_entered_lit = 
cont> and major='AR' and college_code > 0 - 
cont> order by college_code; 



199109' - 



(Note: The "cont>" simply indicates a 
previous line ) • 



continuation from the 



This produced a list of Architecture majors who entered the 
University in the Fall of 1991 and who had transferred from another 
institution. Similar reports were done for the other terms of the 
1991-92 academic year. The resulting lists were then combined and 
could be sorted by the College by either student number, last name, 
or college code. Many other fields are available in the data base 
which could also have been used, depending on user requirements. 
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STUDENT NUMBER 



LAST_NAME 

WOLF 

PUROL 

LENTZ 

STRAUSS 

STALLONE 

ROBERTS 

MALTBY 

DEYOUNG 

CHIODINI 

JACKSON 



COLLEGE CODE 



074948 
075009 
075016 
074984 
074959 
074949 
074971 
075013 
074240 
074580 



904 
1011 
1035 
1051 
1083 
1095 
1106 
1201 
1201 
1201 



Figure 1: entering transfer students and college code 

(2) The Registrar's Office needed to make sure that the degrees 
for June 1992 graduates were conferred correctly. Each degree 
is posted individually, and there is always the possibility of 
a data entry error. The SQL query to check degrees posted in 
June, 1992, looks like this: 



SQL> select a. student_number, a. degree, b.last_name, 
cont> b.firstname from degree_granted a, studentjprof ile 
cont> b where a . degree_date » '199206'; 



The resulting list was then sorted in alphabetical order by major, 
making it easy to check against the hard copy Commencement program. 



(3) The Dean of Arts and Science and the Dean of Students wanted 
to find students who entered the University during a certain 
term, and who were "first time in any college", that is, not 
transfer students. 



SQL> select distinct student_number, last name, first_name from 
cont>student_prof ile where date_entered_lTt ~ "199203" and 
college_code = 0; 
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STUDENT_NUMBER 


LAST_NAME 


FIRb x_I<AMr. 


075531 


SHANNON 


ar>r\mm 

oLUTT 


075532 


LLEWELLYN 


DARRIN 


075535 


ROCKWELL 


CINDY 


075537 


DAWSON 


REBECCA 


075538 


STANDEN 


JOANNE 


075539 


FILARY 


ROBERT 


075540 


LEWIS 


STEVEN 


075541 


CHAMBERS 


AIMEE 


075543 


HOLMQUIST 


DANNY 


075544 

* 
* 
* 


EOZYK 


DAVID 



Figure 2; entering FTIAC students, March 1992 



The AIS stores a numeric code which can be translated into the 
institution the student transferred from. If the college code is 
zero, that student is probably "first time in any college". 
Another way to approach this problem would be to search by high 
school graduation date. 

(4) The Registrar's Office needed a list of student numbers to 

mail Fall registration materials to eligible students. This 
is slightly more complicated, in that students who are 
academically ineligible to re-enroll cannot receive this 
mailing. 



SQL> select distinct student_number from student_prof ile where 

cont> last_term_attended > "199207") and 

cont> student_number not in (select student_number from 

dismissal where date_of_dismissal > ' Ol-Aug-1992 ' ) ; 



The above finds students who attended during academic year 1992-93 
and were not dismissed from the University. The resulting 
electronic list of student numbers is used as input to a program 
that produces mailing labels. 
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STUDENTJHUMBER 

006115 

013774 

016948 

017357 

017762 

018178 

018527 

019824 

019963 



Figure 3: student numbers for mailing labels 

Although not a programmer, the Registrar has learned to write some 
programs that make use of SQL statements imbedded in a Fortran 
program (other languages can also be used). An example of such a 
program can be found in Appendix B. As mentioned above, one 
advantage of using embedded, as opposed to interactive, SQL is that 
data may be "saved" in a temporary table to avoid repetitive 
queries . 

In addition to the Registrar, the LVCET director and the Director 
of Institutional Research and Academic Planning are using 
interactive SQL to help meet the reporting needs of our offices and 
user departments. The EDCC staff is always helpful with technical 
advice and assistance. Some registrars might say, "that's the 
computer center's job", but at Lawrence Tech, we recognize that the 
registrar must act as an advocate and proponent of the student 
records system. 

The ability to meet requests for special information or mailing 
lists has developed a closer relationship and understanding between 
the Registrar's Office and other campus departments. Apparently 
simple requests ("give me a list of all my majors") must often be 
analyzed before they can be filled: "currently enrolled students 
only, or all majors? what about dual majors? current this 
academic year or current this term?" and similar questions must be 
answered so that the resulting report meets the user's 
expectations. This interaction has lead to an appreciation of each 
other's needs. SQL has given the registrar one way to respond to 
these needs. 



Appendix A: tables comprising the STUDENTJNFO database 



TABLE NAME 
DEGREES 

DEGREE_GRANTED 

DISMISSAL 

GPA 

G R ADE_CH ANG E 

GRAD_GPA 

IDENTIFY_LOG 

MESSAGES 

NEXT_STUDENT_NUMBER 

OPTIONS 
OPTIONS_LOG 

OUTSIDE_CREDIT 

STUDENT_MESSAGES 

STUDENT_PROFILE 

TOTALS 
TRANSCRIPT 
TRANSCRIPT_MESSAGES 
USER PROFILE 



DESCRIPTION 

names of all degrees 
offered in last 20 years 

individual degrees 

Individual dismissals 

calculates the grade point average 

individual students' grade changes 

graduate GPA 

counts of fields accessed through 
Identify Students screen 

list of current registration holds 

calculates the next new student 
number 

list of majors/concentrations 

counts of main menu options 
selected 

individual students' transfer credit 

individual registration holds 

4 screens of information on each 
student 

summary totals used for report cards 
student term data 

degrees, certifications and dismissals 

access types and privileges for each 
user 
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Appendix B 



- Example of Fortran program using embedded SQL 



c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 



c 
c 
c 
c 
c 
c 
c 
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c 
c 
c 

c 
c 
c 
c 

c 
c 
c 
c 
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This program will select RECORDS FROM A DATABASE AND 
MATCH IT AGAINST AN EXISTING FILE 



BASIC PROCEDURE: 

1. OPEN DATABASE 

2. BUILD A CURSOR 

a cursor is a temporary table where records can be 

accessed one 
at a time. 

3. DO WHILE DATA 

FETCH or read A RECORD FROM THE CURSOR 
IF THIS IS THE RECORD WANTED 

PRINT RECORD 
END IF 
ENDDO 



THIS PROGRAM MAKES USE OF IMBEDDED SQL. 

SQL STATEMENTS ARE NOT TERMINATED WITH A " ; " BUT WITH A 
CARRIAGE RETURN, AS IN FORTRAN. EACH SQL STATEMENT IS 
PREFACED WITH "EXEC SQL". 

(NOTE: Not all interactive commands are valid in 

precompiled 
programs. Consult SQL manual.) 

IMPLICIT INTEGER (A-Z) 

SQLCOD (OR SQLCODE IN OTHER LANGUAGES) IS AN INTEGER 
VARIABLE 

THAT CONTAINS THE STATUS OF EVERY SQL STATEMENT. 
IF SQLCOD = 0 THEN SUCCESSFUL. 

IF SQLCOD = 100 THEN ATTEMPT TO GET RECORD BEYOND RECORD 
STREAM. 

IF SQLCOD < 0 THEN FATAL ERROR. 

(see sql reference manual appendix D for complete list of 

values 
for SQLCOD) . 

INTEGER*4 SQLCOD 

SET UP VARIABLES AND DATA TYPES TO RECEIVE DATA FROM THE 
DATABASE . 

C HARACT E R I D * 6 , FNAME * 1 1 , LNAME * 2 0 , 1 NPUT_I D * 6 



DECLARE DATABASE 



EXEC SQL attach 'filename admindisk:student_info' 
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EXEC SQL set transaction read only 

C 

C DEFINE A TEMPORARY TABLE CALLED A CURSOR. THIS 

C CURSOR IS CALLED "TEMP" . 

C 

EXEC SQL DECLARE TEMP CURSOR FOR 

SELECT STUDENT_NUMBER, LAST_NAME, 

FIRST_NAME 

FROM STUDENT_PROFILE 

WHERE LAST_TERM_ATTENDED = '199212' 

AND MAJOR = 'BA' 

C OPEN TABLE FOR USE 

C 

EXEC SQL OPEN TEMP 

C 

C GET ONE RECORD FROM THE CURSOR. 

C 

EXEC SQL FETCH TEMP INTO 

:ID, : LNAME , : FNAME 
IF ( SQLCOD . NE . 0 ) THEN 

ID = '999999' 
END IF 
LS=LS+1 

READ (10,15, END=5 ) INPUT_ID 
15 FORMAT (A6) 

LI=LI+1 

GOTO 10 
5 INPUT_ID=' 999999' 

10 CONTINUE 
C 
C 

C DOWHILE (ID. LT. '999999' .OR. INPUT_ID. LT .' 999999 ' ) 

C 
C 

IF (ID . EQ. INPUT_ID) THEN 

EXEC SQL FETCH TEMP INTO 

:ID, : FNAME, : LNAME 
IF ( SQLCOD . NE . 0 ) THEN 

ID='999999' 
ENDIF 
LS=LS+1 

ELSE 

GO TO 110 
ENDIF 

HO WRITE (11,111) ID, FNAME, LNAME 

111 FORMAT ( A6, All, A20) 

120 CONTINUE 

ENDDO 
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C CLOSE CURSOR 

C 

EXEC SQL CLOSE TEMP 

C 

C CLEAN UP EVERYTHING 

C 

EXEC SQL DISCONNECT DEFAULT 
END 
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Interactive Voice Response Technology - 
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Genene C. Walker 
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Tempe, Az. 85287-0101 
Phone: (602) 965-2284 
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INTRODUCTION 

Arizona State University is among the many institutions 
in higher education using Voice Response Technology, Student 
enrollment is over 43,000, ASU is a multi-campus university 
located in a large metropolitan area. Most students commute 
rather than live on campus. Less than 10 percent of the 
student population live in the residence halls. Since the 
mid-80 's, colleges, universities and community colleges have 
continued to implement this very beneficial and popular 
technology to provide convenient and efficient service to our 
customers - the students. 



BACKGROUND 

The decision to provide an alternative registration 
method to on-line and (batch) pre-registration^ was made in 
August 1989. Because tuition fee payment is an integral part 
of the registration process, it was quickly determined a 
touch-tone telephone fee payment system was also needed. 

In November 1990 InTouch, ASU's Interactive Voice 
Response (IVR) System, was implemented. A small pilot was 
successfully conducted using a Syntellect, Inc. 96 line IVR 
system. Enhancements were made to the system, and in April 
1991 a second pilot, with a larger group of students, was 
conducted. Planned capabilities and twenty-four telephone 
lines were added to the system in November 1991. InTouch was 
then available to all students for spring 1992 registration 
and fee payment. In July 1992, a Credit Card Authorization 
feature was implemented. A Class Status feature was available 
November 1992, 

ASU plans to implement a Grade Inquiry system in May 
1993. This will give students the opportunity to call from 
any touch-tone phone to find out their grades, Grade Point 
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Average, Probation status and so on. Other anticipated 
applications are: Financial Assistance Inquiry, a Parking 
System and an Admissions Verification System. Figure 1 
reflects the implementation phases and features of InTouch. 



• August 1989 


Project initiated 


• November 1990 


InTouch Phase I pilot 


• April 1991 


Phase II pilot 


• November 1991 


Phase III - all students 


• July 1992 


Credit Card Authorization 


• November 199 2 


Class Status 


• May 1993 


Grade Inquiry 




Financial Aid Inquiry 




Parking 




Admissions Verification 



Figure 1. Implementation Phases and Features of InTouch 



SYSTEM CONFIGURATION OVERVIEW (Appendix A) 

Syntellect ! s IVR units can connect to a telephone company 
Central Office (CO) , a Private Branch Exchange (PBX) or 
Automatic Call Distributor (ACD) telephone system. The 
telephone lines must be compatible with touch-tone service and 
support a standard touch-tone phone. To avoid over-loading the 
University's PBX during peak call periods, the 120 telephone 
lines connect directly from the local telephone company CO. 

We have two Emperor cabinets housing 60 lines each 
(five, 12 line Premier modules) . Terminal connection is 
through an IBM 3745 controller. The host computer is an IBM 
3090. In addition, we have multiple data logging and 
monitoring sites and a four line Premier IVR application 
development unit. 



INTOUCH FEATURES 

A brief summary of InTouch features follows: 

INTOUCH REGISTRATION SYSTEM (Figure 2) 

Within the Registration System, students may purchase 
health insurance or a yearbook. Once registered, students may 
add or drop clashes as well as withdraw from classes. 
However, complete withdrawal from the University must be done 
in-person. 



Students can hear a list of their classes in two ways: 
(1) A M Quick List" provides the class Schedule Line Number, 
Course Prefix and Number such as: SLN 12345, ENG 301. (2) A 
"Complete List" includes the class meeting time and the 
building and room locations, 

A Class Status option informs students whether a class is 
available, full or canceled. Feedback from students in the 
first two pilots indicated this feature would be very helpful. 
It is especially useful when attempting to drop one class and 
add another. In most cases, if students knew the class they 
wished to add was not available, they would never drop the 
original class. This feature also reduces the number of 
accesses to the registration system attempting to find 
available classes* Also, within the Touch-tone Registration 
System, students may select the Touch-tone Fee Payment System, 
hear the above mentioned options again or end their phone 
session. 



1 


Registration 




• purchase health insurance 




* purchase yearbook 


2 


Drop/Add 


3 


Class withdrawal 


4 


Quick list of classes 


5 


List classes (time/location) 


6 


Class status 


8 


Fee Payment System 


9 


Repeat options 


0 


End this phone session 



Figure 2. Registration System Features 



INTOUCH FEE PAYMENT SYSTEM (Figure 3) 

<r 

If callers select the InTouch Fee Payment System menu, 
students may choose the Credit Card option to pay their fees 
with Visa, Master Card or a debit card. Students receiving 
financial assistance may also apply their aid award to pay 
their registration fees after the first disbursement period 
which is usually the first day of classes. Before the first 
disbursement date, an Accounts Receivable method of payment is 
generated, then Financial Aid is used at the proper time. 

Students who prepay, overpay, drop or withdraw from 
classes are automatically mailed refunds at the end of the 
refund period. If a student anticipates no further 
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registration activity, a refund can be requested and received 
by mail within two weeks. Students may change their health 
insurance coverage by adding or dropping coverage. Students 
can hear an itemized list of charges including class fees, 
deposits and miscellaneous fees such as lab fees. 

By providing payment instructions, the number of phone 
and in-person inquires have been greatly reduced. Three of the 
most common questions asked by students are: 

• What is the Fee Payment Office mailing address? 

• By when do I have to send my fees in to not lose 
my classes? 

• Where do I go on campus to pay in-person? 

Also from this menu, students may choose to return to the 
InTouch Registration System, hear the above mentioned options 
again, or end their phone session. 
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Pay with credit card 




• credit card 




• debit card 


2 


Pay with financial aid 


3 


Request refund 


4 


Add/Cancel health insurance 


5 


Itemized list of charges 


6 


Payment instructions 




• office address 




• postmark deadline 




• payment locations 


8 


Registration System 


9 


Repeat options 


0 


End this phone session 



Figure 3 . Fee Payment System Features 



INTOUCH CREDIT CARD PAYMENT 

Few colleges and universities with telephone registration 
systems have implemented real-time credit card payment. 
Working with Syntellect and Valley National Bank (VNB) , ASU 
now provides this service to our students. 

The credit card authorization application connects ASU 
with Valley National Bank's authorization system. This 
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connection is via a standard leased telephone line with a 
modem dial backup system. The backup system is only used in 
the event the dedicated leased line fails. ASU has not had a 
need for the backup system thus far. 

Each credit card payment takes less than one minute. A 
"Point of Sale" transaction is electronically created and sent 
from ASU to VNB. VNB ' s system electronically provides InTouch 
with the transaction response. The response indicates 
approval or disapproval. Disapprovals can be because of a 
referral condition or an error condition. Referrals represent 
requests on the part of VNB for more information from the card 
holder such as an address or contact phone number. These 
payment requests are posted then the Student Fee Payment 
Office follows-up manually with each caller. If disapproved 
because of insufficient balance, an expired card, and so on, 
InTouch allows the student to use another credit card and 
resubmit the payment request. If approved, the student's 
credit card is charged and ASU ' s computer system is updated 
with the student's payment. 

Figure 4 summarizes credit card statistics collected from 
July 13th to August 23rd. This was the six week period before 
the start of the fall semester, immediately after 
implementation of the system. 

Credit Card statistics reported over 96 percent of the 
payment requests were immediately approved. The option to pay 
by credit card was selected over 6,000 times. Of these, 5,673 
completed the process resulting in 5,493 payments immediately 
approved by VNB and 180 declined. After following up with the 
students, ASU's Student Fee Payment Office manually cleared 
102 of the 180 declines using "Point of Sale" units in their 
office . 



Transactions 


Activity 


6,043 


Pay with credit card 


5,673 


Completed credit card process 


5,493 


(9 6.8%) CC payments approved 


180 


CC payments declined 


102 


(56.7%) approved manually 



Figure 4. Credit Card Statistics 7/13/92 - 8/23/92 

SAVINGS 

The most significant savings realized using this 
technology at ASU and other institutions of higher education 
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are reallocation and/or reduction of full-time and part-time 
staff in Fee Payment and Registrar areas. Also, reductions 
of: 

♦ overtime 

♦ forms and paper 

♦ processing and handling time 

♦ phone and in-person inquires 



BENEFITS 

The greatest benefits are: 

♦ privacy 

♦ security 

♦ reduced workloads 

♦ immediate feedback on credit cards 

♦ immediate feedback on aid payments 

♦ more hours of availability 

♦ fewer students waiting in lines 

♦ convenient and efficient access 

♦ convenience to students 

InTouch requires entry of a nine digit ASU-ID number and 
a four digit Personal Identification Number (PIN) before 
callers can use the system. The PIN is initially set to the 
students birthdate (month/day) . The caller must change this 
number to a PIN of their choice when first accessing the 
system. 

InTouch is available Monday through Friday, 7:00am to 
9:00pm, Saturday 7:00am to noon, and Sunday noon to 6:00pm. 
Because of high volume nightly production processing, the 
system is not available 24 hours a day. 

Before InTouch, there were occasions when students would 
"camp out" all night at the registration sites to be at the 
front of registration lines. This no longer happens. Also, 
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the number of students overcome with heat stroke waiting in 
115 degree heat in sunny Arizona has been greatly reduced! 

All students may use InTouch during hours of 
availability. Because on-line registration and pre- 

registration are available, ASU has not had to schedule 
student access by academic level, or some other method. 



INTOUCH VS. IN-PERSON REGISTRATION 

The most often heard response from students is how easy 
and convenient this technology is to use. One of the 
Registrar Office 1 s favorite anecdotes about the InTouch/In- 
person registration experience happened during the spring 1992 
semester. A student was waiting at an in-person, on-line 
registration site when the site opened Monday morning. The 
student wanted to add needed classes to her schedule. As the 
site worker was processing her registration Course Request 
Form, the student started into a lengthy explanation. She had 
gotten up very early, hired a sitter to watch her children and 
bought gas for her car to drive to campus from the far west 
side of town. She was pleading with the site worker to find 
classes for her. The site worker asked if she was aware of 
InTouch, which is available to all students. She could have 
called on Sunday with a better chance of getting her classes. 
The student replied: "Yes, I know about InTouch, but, I would 
have had to pay for the long distance call. 1 ' The staff 
workers were speechless. After the student left, the site 
workers checked to see if the student was registered for any 
math classes! As of October 1992 U.S. West eliminated toll 
charges within the Phoenix metropolitan area. Therefore, this 
will no longer be of concern to most students! 



CONCLUSION 

Obviously, not all students are taking advantage of 
InTouch by using any touch-tone phone to take care of their 
registration and fee payment needs. However, most students 
are . 

Using interactive voice response technology at ASU 
continues to be tremendously successful. Using InTouch to 
register, drop and add classes doubled in fall 1992 compared 
to the previous semester. Students are taking advantage of 
this service vs. the traditional, less convenient, in-person 
services . 
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INTRODUCTION 

The transcript is the physical document which provides 
evidence of a student's academic achievement. In the past, great 
care has been given to the creation of the physical document. The 
quality of the paper, the beauty of the script, the elaborate seal 
all conveyed the importance of the document. The document itself 
was a treasure. Today, the value of the transcript is not enhanced 
by its physical nature, but by how quickly the information included 
in the document can be shared with those who want to use it. In 
many cases, the physical document is a hindrance. It takes time to 
create; it's expensive to transport; it's open to forgery; it 
takes space to store; and it's not easy to retrieve. This paper 
discusses the steps that ASU has taken to advance the revolution 
from paper transcripts to those in electronic form. 



OVERVIEW OP ARIZONA STATE UNIVERSITY 

University Background 

Arizona State University is part of a three university system 
governed by the Arizona Board of Regents. The other members of the 
system are the University of Arizona in Tucson and Northern Arizona 
University in Flagstaff. Founded in 1885, ASU has 12 colleges and 
schools. The main campus is located in Tempe within metropolitan 
Phoenix. The west campus, recently accredited by the North Central 
Association, serves western Maricopa County. ASU's total 
enrollment is over 4 3,000 students. 

ASU is primarily a commuter school. About twenty-five per 
cent of our students are graduate students. A significant number 
of undergraduate students come to ASU with transfer courses. Over 
fifty percent of yearly transfer students come from the local 
Maricopa Community Colleges. ASU West offers primarily an upper- 
division curriculum so all its students have completed courses at 
other institutions. The information received on transcripts is an 
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integral part of many admissions decisions and used in academic 
decisions throughout our students 1 academic careers. 
Technical Background 

The central computing organization at ASU, Information 
Technology (IT), provides a wide variety of computing products and 
services. Centralized administrative computing is supported by two 
IBM mainframes: a 3090 500E and a 3084. Administrative student 
systems are developed in COBOL in an IDMS environment. 

Data communications take place over a campus broadband 
backbone (ASCII packet and Ethernet) and via direct coax connected 
terminals using IBM SNA protocol. Most administrative computing 
uses direct connected terminals, but ASU is evolving toward a 
TCP/IP standard for Ethernet communications in both academic and 
administrative computing. ASU is connected to the Internet but has 
not used it for administrative data communications. ASU 
administrative systems use SUPERTRACS from Sterling Software to 
send/receive data to/from other organizations. 

Administrative Applications Background 

ASU's student applications are highly integrated, using a 
common Student Information Systems (SIS) database. SIS 
applications interface with business applications. These systems 
were developed in house by ASU technical staff. We expend 
significant effort in maintaining these systems. The electronic 
transcript sub-system is part of the Student Records and Admissions 
systems within the SIS. 



LAYING THE GROUNDWORK 

The groundwork for many changes occurs long before the change 
is envisioned. Your institution may have started the process 
toward electronic transcripts without realizing it- This was the 
case at ASU. 

Academic Record in Electronic Form 

Arizona State University installed a new Student Information 
System in 1980. One of the key differences in the new system was 
that the student's complete academic record was kepc on the data 
base. The data base allowed on-line display of the transcript and 
the creation of a complete printed transcript. The new system had 
many benefits. The one that was important for the electronic 
transcript was that the academic record was stored in electronic 
form in one place. 
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Repository for Incoming Transcripts 



The Arizona Board of Regents changed undergraduate admissions 
requirements for Fall 1987 admissions. The new requirements stated 
that incoming students must be competent in several subject areas. 
This new policy triggered a substantial revision to the Admissions 
systems at ASU. The revised admissions system captured information 
about the individual courses a student completed in high school or 
at other post-secondary institutions. The individual course 
information has benefitted evaluators and advisors. This system 
component was important for the electronic transcript project since 
it provided a place to store incoming transcript information in 
electronic form. 





REPOSITORY FOR INCOMING TRANSCRIPTS 


ELECTRONIC ACADEMIC RECORD 



Figure 1 



LOCAL EFFORTS 

When Arizona State University began discussing electronic 
transcripts with its neighbors in the Maricopa County Community 
College District in 1988, we were not planning to change the world. 
We wanted to solve a local problem. Being close geographically, 
the two institutions serve many of the same students. 
Approximately 15,000 transcripts are sent back and forth each year 
between the colleges and the University. Admissions and Registrar 
offices have seen benefits from this local exchange. The benefits 
received from this local effort convince us to push for broader 
change. 

To provide electronic transcript exchange, ASU made changes to 
its systems and procedures. 

Data Communication Outside ASU 

Arizona State University computers are connected to various 
other computing facilities. This connection has been primarily for 
academic activities and electronic mail. Connection outside of ASU 
for administrative computing was very limited. One method we had 
used was to dial-up another computer using a PC and modem. This 
worked but required operator intervention and the line speed of the 
regular phone line presented problems for large data transmission. 
To support the electronic transcript exchange and other data 
exchanges, ASU purchased SUPERTRACS in 1988. SUPERTRACS runs on 
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the IBM mainframe, supports unattended operation and connection, 
stores data received/sent from another computer, validates 
passwords, and provides security for administrative systems. 
SUPERTRACS benefits any administrative system which wants to 
connect outside the university. 

Communications Network 

Arizona State University and the Maricopa District Office were 
already connected by a dedicated phone line when we began 
electronic transcript exchange. The colleges within the Maricopa 
District were also linked to the District Office. The electronic 
transcript exchange used the existing network. Electronic 
transcripts became another use for an existing network. 

Cooperation of Stakeholders 

Exchange of electronic transcripts by definition implies a 
cooperative endeavor. Several work groups formed in the course of 
the project. Representatives from Undergraduate Admissions, 
Readmissions/Records, and Graduate Admissions met with computing 
services staff to determine how each office wanted to receive and 
process transcript data. Staff from ASU and Maricopa met to define 
transcript format and operations schedules. Computing services and 
admissions/records staff from both organizations met to review and 
confirm system tests. The project required many offices to examine 
their assumptions/procedures and reach consensus with others 
involved. The lessons we learned by working with each other 
improved our organizations. The cooperative spirit serves us as we 
continue to work together. 

Format, Rules and Procedures 

No national standard existed in 1988 when ASU and Maricopa 
began their electronic transcript exchange. Both institutions met 
to identify data included in their transcripts. We developed a 
format that included all the data included in either transcript. 
We also defined the expected and required content of each field. 
Procedures were developed for future review of the format. To 
accept the new electronic transcripts as official, required policy 
changes. The governing bodies for ASU, the Arizona Board of 
Regents, and the Maricopa Community Colleges, the Maricopa County 
Community College Board, accepted the electronic transcript as 
official. This set a precedent for the possible future exchange of 
other official documents. 

System Revisions 

ASU received incoming transcripts from Maricopa in phase one. 
To accept transcripts, we added a new sub-system. This system did 
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not change the existing admissions systems but added a new way of 
putting information into the system. New programs verified 
incoming transcripts, matched them with applicants/students, 
determined the interested office(s), printed the transcript or 
added transfer courses directly to the student record, $>thcr new 
programs supported office staff by recycling unmatched transcripts, 
providing methods to manually match, post or print any transcript, 
and purging transcript files. 

The second phase of the exchange had ASU send transcripts to 
Maricopa. We needed to enhance the transcript request process. 
Prior to the electronic transcript exchange, the transcript request 
process was limited to asking for copies of an individual 
student 1 s transcript. Electronic transcript exchange was the 
impetus to revise the request process. Enhancements added the 
ability to request transcripts in the future, display requests on- 
line, produce computer generated addresses, track transcripts fees, 
and retain electronic data about transcript requests. Other new 
programs were added at the end of the transcript creation process 
to create transcripts in electronic format. 

Trading Partners 

The local exchange has been sending transcripts to ASU since 
1989 and sending transcripts to Maricopa since 1991. One 
difference between this system and many other systems we use at ASU 
is that its continued success and operation relies not only on us 
but also on the Maricopa systems. ASU and Maricopa continue to 
communicate to ensure the smooth functioning of the system. We 
need to act as partners as we plan for future expansion and 
enhancement. 
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Figure 2 
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LOCAL BENEFITS 



The electronic exchange of transcripts has brought benefits to 
both Admissions and Registrar's Offices- This exchange method: 
eliminates manual procedures to mail the transcript; cuts delivery 
time; provides automatic matching of over 95 percent of incoming 
transcripts; cuts time and errors associated with data entry; 
reduces postage and paper costs; and saves clerical effort and 
space needed to file paper documents. We have also discovered the 
ripple effect of improving our systems. Phone inquires ara 
reduced. Turnaround for admissions and transfer credit decisions 
is lessened. Transcript request information is available more 
easily. Transcript requests are entered with a more even workload. 
We believe these initial steps are investments for greater benefits 
in the future. 



NATIONAL EFFORTS 

National Format 

The American Association of Collegiate Registrars and 
Admissions Officers (AACRAO) appointed a task force in 1988 to 
develop standards for electronic exchange of educational records. 
This group along with a parallel task force created by the National 
Center for Educational Statistics developed a national standard to 
exchange electronic transcripts. The transaction set 13 0^ was 
formally approved by the American National Standards Institute 
(ANSI) X12 committee in February 1992, For institutions starting 
the development of electronic transcripts, the presence of a 
national standard saves considerable time, 

Arizona State University strongly supports the efforts to 
expand the number of institutions using the X12 standard. In 1992 
we began a project to expand our current electronic transcript sub- 
system to use the national standard in place of the local^ format 
developed for the Maricopa exchange. To accomplish this, ASU 
purchased STX12, an EDI translation package, from Supply Tech, We 
modified an existing program to add data items needed by the 
national standard. We added new data communications procedures to 
connect to the GEIS (General Electric Information Services) network 
so we could transmit to others using the national standard. With 
these minor enhancements, we have been able to experiment with 
others piloting the new SPEEDE standard. 



NEXT STEP 

There are many next steps to advance the revolution in 
electronic data exchange, Arizona State University sees many next 
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steps for itself and others. Some definite next steps we have 
actively considered are: 

* complete conversion of the Maricopa exchange to the 
national standard 

* expanding the exchange to high schools in Arizona 

* sending transcripts to the state Department of 
Education for teacher certification 

* adding additional postsecondary institutions 

* using the transcript as part of a transfer 
equivalency system 

* expanding data exchange to other transactions. 



NEXT? 
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Figure 3 



CONCLUSION 

Arizona State has seen benefits as it has taken each step in 
this changing environment. Electronic data exchange is a 
technology which gives immediate benefit and builds an 
infrastructure for more benefits in the future. 

As colleges and universities try to do more with less, ASU 
continues to invest in electronic data exchange. Other industries 
have demonstrated the benefits of this technology. It is only a 
matter of time before electronic transcripts are the primary method 
for sending educational records* That day will come more quickly 



103 

— 111 — 



if other institutions add their talents and resources to the 
effort. Join the revolution. 
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GIVE CREDIT WHEN CREDIT IS DUE: 
AN ON LINE STUDENT CREDIT SYSTEM FEATURING ON-DEMAND CHECKS 



Marty Werneke 
Application Coordinator, Finance and Administration 
Central Missouri State University 
Humphreys Room 222 
WarrensburQ, MO 64093 

(816) 543-4895 
WERNEKE@CMSUVMA 

Central Missouri State University, founded in 1871, consists of 1050 acres located 50 
miles east of Kansas City in Warrensburg, Missouri. Between the four colleges of Applied 
Sciences and Technology, Arts and Sciences, Business and Economics, and Education and 
Human Services, students may earn Associate, Bachelors, Masters or Education Specialist 
degrees from 150 areas of study. As of September 16, 1992 enrollment at Central was 
approximately 12,000. As with many universities, a large portion of that population is on 
some form of financial aid. At Central, this is generally around 55 - 60 percent. 

The department of Information Services provides the university with a variety of 
computerized systems which support the university's administrative functions, A few of 
Central's major H in-house H developed on-line systems consist of: 

Personnel/Payroll (1978, DL/I) 
Student Registration (1968, VSAM) 
Total Transcript (1981, DL/I) 
Revenue (1972, VSAM and DL/I) 
Financial Aids (1979, DL/I) 
Facilities Inventory (1988, DL/I) 

Within the past several years, Central has purchased and installed four package systems: 

College and University Finance System 

(CUFS, 1983, American Management Systems) 
NOTIS (1984, Northwestern University) 
Alumni Development (1992, Information Associates) 
Degree Audit Reporting System (DARS, 1 992, Miami University) 

Management applications are supported by an IBM ES9121-210 Central Processing Unit 
with 64 Megabytes of memory. Central's mainframe operating systems is DOS/VSE/ESA. 
Peripherals include 1 IBM 3990 disk controller, 4 IBM 3380 high density disk drives, 3 IBM 
3420 tape units, 1 IBM 71 71 protocol converter, 1 IBM 3820 laser printer, 1 IBM 3203 printer, 
1 STC line printer and a number of IBM 3 1 74 terminal controllers. One of the 31 74 controllers 
Includes a Token Ring backbone. Support if, provided to over 600 devices through coax 
attachment, Token Ring and Apple Local Talk networks. 

HISTORY OF STUDENT REGISTRA TION A T CENTRAL 

As listed above, Central's revenue/registration system is over 20 years old. This system 
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has served the university well, but as policies and procedures evolved, the system became 
increasingly harder to maintain. The student registration system allows pre-enrollment for the 
next semester to begin two weeks after the current semester starts, Students' fee charges 
are generated and/or adjusted immediately upon a change in enrollment, Residential life 
charges are also generated upon assignment to a residence hall. Several years after 
implementation of the registration system the financial aid system was added which allowed 
personnel to enter financial aid information as student award letters were returned. Students 
were able to pay their charges at any point in time after the charges were incurred, While this 
typo of systom may be miles ahead of the old port-a-punch and mass enrollment methods of 
the past, changes in policies and procedures resulted in many problems which had to be 
addressed, 

Typically, there are always a very large number of enrollment (drop/add) changes for a 
student, Because of current file limitations, it became nocessary for us, under certain 
circumstances, to purge courses that had been dropped by the student from on-line records 
in order to handle his current enrollment. Results were, of course, inaccurate reporting and 
potential fee calculation errors. Central's refund policy (first week - 75 percent, second week - 
50 percent, third week - 25 percent) only compounded the difficulty in recalculating fees 
accurately. Tracking a student's financial record became difficult to say the least. 

Loans, grants, and scholarships, were manually entered to a DL/I database as a student's 
paperwork was completed, The terminal operator was responsible for entering the amount for 
each type of aid/award, A "pre-run" report was produced two days prior to financial aid 
application, It became a manual effort at that point to review all students to determine 
whether or not adjustments were necessary. While those reviewing tho report found many 
discrepancies, the potential for over-awarding was definitely present. 

Another problem with the previous method of applying financial aid was the volume of 
checks which were voided each semester. An application run was made approximately every 
two weeks and checks were produced at that time. These signed checks would remain in the 
Revenue Office until either the students picked them up or financial administrators determined 
that they should be voided, 

The student receivables billing also left much to be desired, Bills were printed on mailer 
forms which, because of space, limited the number of charges detailed to 12 and number of 
awards to five. Payments were never reflected. As a result, billing was much too vague and 
confusing. 

SOMETHING HAD TO BE DONE! 

It was decided that a "credit" system would be beneficial to the university's operation. 
Beginning spring '91, countless hours were spent by a committee of representatives from 
Revenue, Admissions, Accounting, Controller, Athletics, Student Affairs, Financial Aid, and 
Information Services in trying to define the "scholarship policy/credit" project. Federal 
regulations needed interpretation to determine how this new system should handle them. 
Priorities for the application order of awards/credits needed to be defined. A "conflict matrix" 
of valid award combinations and order of adjustment also required definition, Beginning in 
August 1991, the design phase of the student credit portion of the system also began. 
Programming started in late November, 1991. 

There were several limitations within which we had to live including the decision to 
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implement the initial phase of the system for Fall of 1992. Because of pre-enrollment, that 
meant programming must be completed by February 3, 1992. With this short time frame, it 
became apparent that we did not have the time to totally rewrite the existing systems and we 
had to live within the file structures and data available at the time. 

The new credit system was to also include third party credits (ie: vocational rehabilitation, 
veteran, etc.) as well as fee credits (refunds) and cash credits (payments made by the student). 
These new credit types and associated data were defined within new DL/I segments. One of 
the beauties of a DL/I database is the ability to define new segments without changing ALL 
existing programs. 

The majority of the old revenue related on-line functions became a part of the new menu- 
driven system. Some of these functions include student receipting, entering/removing 
charges/credits, and loan repayments. A variety of existing inquiries were added to this menu 
as well as several new inquiries which aid the operator in determining the status of the student 
account. Figures 1, 2, 3, and 4 are a few inquiries which operators find very helpful. 



Figure 1 : INQUIRE STUDENT BALANCE 
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PF1 - PACE FORWARD PF2 - PAGE BACK CLR - EXIT TASK 

PF6 - SUB -MENU PF12 - MAIN MENU PF3 - SET TAOS 



The left aide of this screen reflects the students charges on file up through the year/semester selected. The right 
side shows the svsilsbie credits remaining through the year/semester selected. The top line will show the balance due 
to/duo from the atudent. 
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Figure 2: INQUIRE PAID CHARGES/CREDITS 
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Thie inquiry will reflect til poymente made by the student at well m eny credit epplicetior* which 
hive been potted to hte eccount. Note: The receipt deted 10/31/1892 ie e credit epplicition. All 
credite applied ere lieted. The cesh credit deted 10/26/1B92 (receipt number FOOD indicates e ceeh 
credit forwsrded to • future eemeeter. The student mey elect to reserve ell or e portion of hie 
•veil Able ceeh credite held in reserve for another eemeeter. 



Figure 3: INQUIRE REFUND CREDIT ADJUSTMENTS 
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APPLIED EXCE88 BALANCE MAX 
DATE AMOUNT TO CAftH AMT 

2.210.00 .00 .00 2,210.00 
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An operetor mey view refund credits end cesh credits. This tcresn displtys s non-res credit of 2,210.00 
end ell Adjustments which were mede to srrive et thet figure. 
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Figure 4: INQUIRE APPLICATION INFORMATION 
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P*1 - PAQE FORWARD Pf2 - PAOE 9ACK CLR - EXIT TASK 

PF« - SELECT SCREEN Pffl - RETURN TO SUB Pf 12 - RETURN MENU 



One* en «pphc«tion (or distribution of funds) hss been m*de, th« operetor hee available «n 
inquiry scre«n which will display all credits which ware applied to his account, all 
chsrges which hava besn paid by that credit, snd stso thst tmount of excess over end above 
his chsrges which haa been moved to his cesh credits for future use. 



SECURITY 

Security and a sufficient audit trail were two issues that were addressed during this 
project. The security program developed controls for the data entry of credits and charges. 
At the present time each charge type and/or fee credit type can be entered selectively by up 
to five offices and/or individuals. The program utilizes the CICS operator-id from the CICS SNT 
table in determining the terminal operator's clearance. All charges to a student account can 
be entered on-line by the area of responsibility. Fee charges, however, are automatically 
calculated at enrollment time. There are currently about 25 areas with this capability (i.e.: 
health center, airport, parking, residential life, etc.). Should this number need to be increased, 
it could be done quite easily. With regard to an audit trail, the terminal operator has available 
on-line, all third party credits, fee credits, and cash credits posted to the student's account, 
with all adjustments that have been made to each credit. Any on-line adjustments made will 
also have the operator's CICS operator-id recorded. 

Another method of security added to the H remove charge" function prohibits removing 
a charge unless it was entered the same day. This was a requirement for the new billing 
procedure to be implemented in July. Charges which were entered and removed the same day 
are not shown on the student's bill. However, if a charge is entered one day and later the 
operator determines that the student is no longer responsible for the charge, they must enter 
a credit. At billing time, both the charge and the credit would be reflected. Another control 
measure taken by this security program is to prohibit the capability of entering/removing 
charges by the same area which receipts payments. 
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AWARD ADJUSTMENTS 



As mentioned earlier, programming was developed that would automatically, on-line 
adjust a student's credits whenever any function was performed which might alter the amount 
available for each type of credit/award depending on the conflict matrix and rules developed. 
The adjustment program will find conflicts such as Distinguished Scholar and Foundation Merit, 
Regents-in-state and Regents-out-of-state, and Distinguished Scholar and Regents. In these 
situations, the student can not have both. In the case of the Distinguished Scholarffull ride) 
and Regents Scholarship, policy dictates that the maximum amount the student can receive 
is the "cost of education". Therefore, the student's Regents Scholarship will be adjusted to 
zero. Another example of this adjustment is PELL. If the student dropped below fulliime, such 
as 9 hours (this is considered 3/4 time at Central), programming would adjust the student's 
PELL award to 75% of the original award. Charges/credits entered will also invoke the 
adjustment program to review the student's account and made necessary adjustments. 

STUDENT RECEIPTING 

There are several receipting functions which may be performed in the revenue office. 
The one referred to in this paper pertains to the student receipting function. To begin with, 
the system is capable of maintaining 35 separate drawers (receipting stations) during the day. 
Each operator has the capability to check at any point during the day to determine the current 
drawer balance. Totals to which the operator must balance include: cash received, special 
deposits, credit card payments (electronically processed), credit card payments (manually 
processed), checks received, and inter-departmental transfers. (Figure 5) Once each operator 
has balanced their "drawer" an operator can display a deposit screen (figure 6), print screen 
the image, and use that to accompany the daily deposits to the bank. 

Figure 5: OPERATOR DRAWER BALANCE 
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An operator may at any point tn the day display their particular drawer balance or the balance of 
•II receipting etations broken down by funds {general or foundation) and by method of peyment. 
The bottom helf of the ecreen reflects the total amount receipted for each station. 
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Figure 6: DAILY DEPOSIT SHEET 
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Whan all receipting stations hava balanced their drawara an operator may display the above screen, 
acreen print and then attach it to the daily bank daposit. 



As with the previous revenue receipting function, students have always had the facility 
to make payments directly to their account at any point after their charges have been incurred. 
We have now taken this a step further by allowing tha student to pay in advance, on their 
account, money to be applied to their charges at a later date. These are referred to as "cash 
credits". 

While tightening many of the controls, the receipting function still maintains a lot of 
flexibility. As the student is processed, programming will send a variety of messages to the 
operator depending on the status of the student (ie: suspended/dismissed, records on hold, 
collection agency account, etc.). The first common screen which is returned, however, on 
every student is one which will indicate all loans, grants, scholarships, fee credits, third party 
billing credits and cash credits available, as well as the total outstanding charges. The operator 
then has a variety of pathways which may be taksn wliile continuing the receipting process. 

Ideally, the student's payment will be recorded as a cash credit. If, however, the need 
arises, specific charges (ie: telephone bill, parking fine, etc) may be selected for direct 
payment. The philosophy taken at Central is that it really doesn't matter what charges have 
been paid or not paid, but only that sufficient credits are available to cover the student's 
charges. In fact, controls have been developed which will prohibit enrollment fees from being 
directly paid. The only way current semester fees can be paid is during batch application of 
credits. An application run, to distribute revenue to the appropriate accounts, is made 
approximately once per month throughout the semester. 

The next common screen that all revenue operators will receive regardless of the pathway 
chosen will allow the operator to indicate the amount of payment and method of payment. 
(Figure 7) This particular screen contains all the information the operator needs to know to 
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complete the function, whether it is receipting a payment, or making a cash withdrawal for the 
student against his/her available credits. 



Figure 7: RECEIPT PAYMENT/CASH WITHDRAWAL 
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TOTAL ESTIMATED CREDIT* AVAILABLE TO DATE ( 1. 700.00) 
UNAUTHORIZED HELL AVAILABLE 



ESTIMATED BALANCE PRIOR THIS SESSION 
RCCBVEO THIS RECEIPTING SESSION 

CASH RECEIVED - 

CHECKS RECEIVED • 300.00 ELECTRONIC 

CREWT CARD • 

IOT RECQVEO - TOTAL- 
CHARGES PAID THIS SESSION 



300.00 
0.00 



AMOUNT AVAILABLE FOR CREDIT THIS SESSION 

INDICATE AMOUNT TO CREDIT THIS SESSION 
CASH BACK TO STUDENT 



300.00 



MAXIMUM ADVANCE POSSIBLE 

PAYMENT PRESENTED (T,M,P| - 



i BOO. 00 ) 



MflEVOSO 

1.B2B.B0 
1.B47.30 
1.B00.00 

2*0.00 



( 1,SS7.S0) 



260.00 
BO.QO 



1.917.S0 



ENTER ONE OF THE FOLLOWING TO CONTINUE PROCESSING: 



ENTER • CALCULATE TOTALS PF1 . CONTINUE PROCESSING 

PFS • CANCEL/RETURN TO SUB -MENU PF11- PREVIOUS PF 12 -CANCEL/RETURN MAIN MENU 
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it the amount of QSL for which the student hae been approved. Six hundr«KJ dollar! n then the amount 
of open caah advancee the etudant hae remaining on file) 



There are sufficient controls within the receipting function which do not allow the 
operators to advance more than the student's credit balance (charges less credits). Two 
LOGONS have been established which will allow the operator the ability to override the 
controls and allow advances up to the total credits available regardless of outstanding charges. 
These logons are seldom used but do accomodate circumstances where family housing is 
charged by the semester and are paid in advance EXCEPT when government loans may be 
credited in two payments. If the second check from the loan has not been received it is not 
required that ALL housing for the semester automatically be paid from the first check, (FIGURE 
8) 



Figure 8: RECEIPT PAYMENT/CASH WITHDRAWAL (OVERRIDE LOGON) 
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AMOUNT AVAILABLE FOR CREDIT THIi ft£££JON f)A 
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CASH SACK TO STUDENT 
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ENTER ONE OF THE FOLLOWING TO CONTINUE PROCESSING: 




ENTER - CALCULATE TOTALS PF1 - CONTINUE PROCESSING 





Thit display it basically the same as figur* 7, however, in the cum where one of the two 'overrida" 
operators is logged on, the maximum advance possible will be the sum ol sll credits svsilsbls (1,667.50). 
sll deposits mede during thit receipting session. less ell open cash advance that the student hoe already 
received since last application (600.00). 

Anytime a check is issued, a corresponding charge is created on the student's account. 
This charge is then paid at the time the application of credits is made. Figure 9 and 1 0 reflect 
the "receipt" screen and the "check issued" screen which can be screen printed and given to 
the student. The receipt screen shows the amount which was credited to the 



Figure 9: STUDENT RECEIPT 



491-32-4682 
DOE JOHN 

198S.W. 13 HIGHWAY 
ROUTE 3F 

CEDAR RAPIDS IA 4862 1 


CENTRAL MISSOURI STATE UNIVERSITY 
WARRENSaURG. MISSOURI 84093 

8ALANCE OF ACCOUNT 
SEM TYPE OESCRIPTION 

911 0041 DROP CHARGE 
902 018 TRAFFIC FINE 

912 016 TRAFFIC FINE 


AMOUNT 

12.33 
100.00 
3.60 


TOTAL RECEIVED 
CHARGES PAID 
CREDITS 


126.00 
116,83 
0.00 










CHANGE 


9.17 










TOTAL REMAINING CHO 
CHECK ISSUED + 
TOTAL AVAILABLE CRED • 


869.98 

360.00 
3600,00 










DUE FROM STUDENT 


( 2.480.02 ) 










METHOD OF PAYMENT - CSH CK CRCD IDT 
VALIDATION • YES 82/2 
PREPAYMENT - NO NEXT SCHEDULED 
FULLPAYMENT • YES PAYMENT DATE 
RECEIPTED 8Y -01 


OTHER 

TOTAL CHARGES Ft). 1 16.93 
ISSUED • 10/16/1992 NO. 3216 09:46:32 



The above diaplay la that of a atudanta receipt for a payment which ha haa mads. The right half of the 
racaipta liata all chargea which ware paid directly by the student. The left portion indicataa the amount 
received from student, total charges selected, amount depoaited aa credit and any changa raturnad to the atudant. 
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Figure 10: CHECK VERIFICATION 



491-32-4682 
DOE JOHN 

199 Ittft.W. 13 HIGHWAY 
ROUTE 3F 

CEOAH R AMDS I A 4BS21 



CENTRA! MIWOUM STATE UNIVERSITY 
WARREN SCURO. MISSOURI M093 

BALANCE Of ACCOUNT 
SEM TYPE OESCRtRTION 
922 001S INTERNATIONAL EXCHAN 
022 001 FEES UNDERGRADUATE 



AMOUNT 

604.00 

1S6.9S 



CO FAY- SO ATM AN S BANK 
TOTAL OPEN CHARGES 
CHECK ISSUED + 



669.98 

350.00 



ACTUAL CREDITS 
ESTIMATED CREDITS 
OtUFNDB/FNDC 
UNAUTHORIZED PELL 



1S97.7S 

0.00 
1802.26 
0.00 



ESTIMATED CREDITS 



< 2480.02) 



CHECK NUMBER • 000000 1 0346 
NEXT SCHEDULED PAYMENT - 12/01/92 
VALIDATION - YES 82/2 
PREPAYMENT - NO 



FULLPAYMENT • YES 



OTHER 

TOTAL OPEN CHARGES 



0,00 
6S9.88 



ISSUED • 10/16/1992 BY ♦ 01 



09;46:32 



When the etudent mtket • withdraw*! •giir»t hie evulible credit belence, the ebove ecreen it returned 
end mey be ecreen printed end given to the etudent. He then hee 'euthoriMtion" to receive the check 
from the employee ttetioned et the check printer. Additional information on thit receipt include* e 
lilt of ell remeining chergee on his record*. If < check ie drewn in two nemee, the copiyee it eleo 
indicated. 



student's account and any charges which were directly paid. The "check issued" screen 
indicates the check number and amount of check, the payee and copayee, and also the 
remaining charges on the student's account. This screen, when printed and given to the 
student, is also used as verification to the employee responsible for handing the check to the 
student, that he indeed is the person to receive it. Central purchased a TROY 410 laser printer 
to print the on-demand checks. The paper utilized is 8 1/2 X 11 inch with two horizontal 
perforations. The top (approximately 1/3) is in blue security stock with the remainder in 
standard white paper (20 lb.). The check number is a system maintained sequential number. 
The check form, variable data, check number, MICR code and signature are printed on the 
blank check form after the operator completes the student receipting function. The signature 
is controlled with the use of a signature font card and key (figure 11). The bottom 1/3 of the 
check is a duplicate with the exception of the micr code and signature. The student must then 
sign on the bottom 1/3 of the form. This portion then accompanies the day-end check register 
to the accounts payable office. 

The TROY printer is an ASCII device and therefore has to be attached to our mainframe 
through a protocol converter. We have an IBM 7171 unit to which the TROY printer is 
attached. The connection from the IBM 71 71 unit to the printer is supplemented with a LONG- 
LINK unit which extends the RS-232 length to a greater distance, and uses 4 twisted pair 
telephone wires. The TROY printer is driven with our system software as a standard 3270 
type printer. 

IMPLEMENTATION 

The fee credit system was implemented in four stages. The first stage was implemented 
on February 3, 1992. When fall 92 enrollment began, programming was in place to enter 
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and/or adjust fee credits. The same coding structure was used for the credit type that was 
used for charges. For example, incidental fees are '001 ' charges so the credit for fees is a 
'001 ' credit type. This allowed for use of our existing Revenue Distribution Database to 
determine the accounts to use in the interface to the CUFS accounting system. The automatic 
on-line adjustment program was also installed at this time and course enrollment was moved 
from the VSAM file to the DL/I database eliminating the course purge problem we were having. 
Also implemented was the change in the method of recording housing and enrollment 
charges/credits. We changed from adjusting one single enrollment charge per semester and 
concurrently updating date of transaction (leaving no trail available on-line) to adding charges 
on upward enrollment hours and credits for downward movement in enrollment hours. This 
was also necessary in order to create the type of student billing statement desired. 

On July 14, Central sent the fall semester 92 student billing utilizing the new billing 
format. This has proven to be a big adjustment for both the students and Central staff. The 
students are receiving statements which reflect all activity in detail whether it is charges 
generated, payments received, or credits issued. The statement also reflects all estimated 
credits available (GSL, PELL, Scholarships, etc.) up through a given year/semester. Also 
calculated is the amount of prepayment which the student must pay in order to retain classes. 
(Central requires a $100.00 prepayment or the students courses will be removed on pre- 
scheduled dates in an effort to free up seats for other students.) The student's statement is 
printed on 8 1/2 by 1 1 inch standard stock form using the IBM 3820 laser (figure 12). The 
new security program which controls the areas which may add charges/credits was also 
installed on July 14. 

August 28 was the date the new check writing function was implemented. This enabled 
the terminal operator to issue the on-demand checks to the student for any excess credits they 
had on their account. 

On October 31, Central processed the first application ot student credits to student 
charges and distributed those funds to the general ledger. The application process utilizes the 
prioritization table of credits and order of charges, paying the charges with the credits available 
to the student and moves any excess credit remaining to the student's cash reserve. Excess 
credits are moved to cash in order to clear the various credit accounts and distribute the money 
from these accounts. The excess moved to the student's cash account may be held to cover 
future charges or be withdrawn by the student on request. 

At the point in which credits are applied to the student's charges any "cash advance" 
charges will also be covered. The only exception to this is within the PELL program. Our 
interpretation of federal regulations show that PELL monies may only be used for fees and 
housing unless the student authorizes the university to use the remainder to pay other charges. 
Therefore, if a student's records show that he has not given the university that authorization, 
that portion which exceeds his fees and housing is held in the PELL account for student 
withdrawal. If it had been added to his cash credit, the money could have been utilized to pay 
other miscellaneous charges. The unauthorized amount remaining is subject to application 
should the student incur more charges which could be considered fees and housing. The 
revenue receipting function also keeps track of those amounts of authorized and unauthorized 
PELL the student is to receive. Also implemented was the interface which distributed the 
funds to the appropriate accounts in the CUFS system. Manual data entry is no longer 
necessary for posting to the general ledger. 
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Figure 1 1 : CENTRAL MISSOUR! STATE UNIVERSITY CHECK 



Central Missouri State University 

Warrensbwg, MO 64093 



DATE " 


~ VENDOR WO. 


11/10/92 


499-70-9120 



ONE THOUSAND SIGHT HUNDRED SEVENTY DOLLARS AND NO CENTS 



■ ThW, lBlfl 
ClTIIIiS JACrSon C0UWIY 
MMUU«J»Uft« MO 

no. 905291 



• AMOUNT 
870 ,00 



PAY TO 
THE 

ORDER OF 



RILEY MELINDA I?» 
113 EAST WALNUT 



CHILHOWEE, MO 64733 




/ 



DETACH AT PERFORATION 



VENOOB INVOICE 



PAYMENT VOOCHER 



OESCfWDON 



11/10/92 



STUDENT CREDIT 
RXLEY MELINDA R* 
499-70-9120 



+ ***!, 870. 00 



O^CT&CK I +«**1.B70.00 



no. 905291 



Central Mlaeouri State Untveralty 
W«n«»burg.MO 640*3 

DETACH AT PERFORATION 



Central Missouri State University 

Warrcnaburg, MO 64093 



DATE 




11/10/92 


499-70-9120 



no. 905291 



RILEY HELINDA R. 

PAY TO 

J^OplU EAST WALNUT 
CHXLtiOHEE, MO 



64733 



i± AMOUNT 
****l t 870 ,00 



NON-NEGOTIABLE 



02 



The ttgure tbove n in tm»ge of the check dfivvn to a ttudent it * CMh edvenca ignnat 
hit tvuleble credits fomnning through • given yeir/temonter. He must sign on the line 
it the bottom. Thi* it retimed by tccounting At ■ duplicate check. 
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Figure 12: CENTRAL MISSOURI STATE UNIVERSITY STUDENT STATEMENT 



MCDONALD RONALD ACCOUNT: 491424193 B4LUNQ DATE: 10/29/1992 



BEOlNNINO BALANCE • ADDITIONS ♦ CREDITS ♦ ACCOUNT BALANCE 

♦260.00 * +1,115.00 ♦ 4-0.00 ♦ 91,999.00 



CURRENT PAYMENT DUE (THROUGH FAU/1 992) + 61 1.00 

♦U£SS ESTIMATED AWARDS (THROUOH FAU/1 0621 * 0,00 

MINIMUM PAYMENT DUE + f 1 6.00 



TOTAL PAYMENT NOW DUE + f 1 §,00 

LUNSfORD ED 
CM»U 

HUMPHREYS 2 1 2 I LOO. 
WAWtNWWQ, MO #4093 



AMOUNT REMITTED j | 



CUr AtONO DOTTED UNE AND REMIT ABOVE PORTION WITH CHECK OR MONEY ORDER TO CM9U 



CENTRAL MISSOURI STATE UNIVERSITY • STATEMENT OF ACCOUNT 49142-9193 



OATE SEM/YEAA 


DESCRIPTION 


ADDITIONS 


CREDIT* 


BALANCE 


02/01/1992 


BALANCE FftOM LAST BILUNO 






+ 260.00 


09/18/1992 FALL/92 


HOUSING. ROOM ONLY 


200.00 






09/21/1992 FALL/92 


HOUSING*. ROOM ONLY 


200.00 






06/22/1992 FAUL/92 


FEES QRAO, 


260.00 






06/24/1992 FAUL/92 


FEES ORAD. 




160.00 




09/29/1992 FALL/92 


FEES UNDERORAD. 


260.00 






07/19/1992 FALL/92 


PAYMENT RECEIVED 


380.00 






09/24/1992 FALL/92 


HOUSJNO.ROOM ONLY 


200.00 






09/21,71992 FALL/92 


PARKILO FINE 




16.00 




09/29/1992 FALL/92 


PAYMENT RECEIVED 




100.00 




10/02/1992 FALL/92 


TRAFFIC FINE 


16.00 






10/19/1992 SPfJNO/92 FEE* ORAD 


960.00 








ACCOUNT BALANCE 


4-2913.00 


916.00 


+ 2449.00 


FALL/92 


ESTIMATED AWARD/AID - PTYO 




80.00 




FALL/92 


ESTIMATED AWARD • PELL 




91200.00 






♦ TOTAL ESTIMATED AWARD/ AID 




+ 1290.00 





TOTAL OWEO +2613.00 +1996.00 +1199.00 



PAYMENTS SHOULD BE POSTMARKED BY JULY 31 . 1992. 

Thlt ntw Wiling tttttmtnt dttcrlbtt tht cutrtnt ttttut of your account. Pltttt ftvttw ctrtfuHy 
tht chttgtt on thlt tttttmtnt at thty wlH tppttr only oitct. Future tttttmtnU will tbow thlt 
tndng btitnct m tltt new btglnnlng btltnot plut new activity on tht tcuount. 

Unlit* you htvt mtdt prior trrenfltmtntt with tht Rtvtnut Offlct. pty tht "tot«l Owed" plut thy 

option* you with to itltct. Cut off tht top portion Indfctttd tnd rtturn with your peymtnt to: 

CENTRAL MISSOURI STATE UNIVERSITY REVENUE OFFICE. WARREN&BURQ, MO. 94093. (91BI-S43-41 17 

To rttaln your cleat tchtdutt tnd bt vtJIdtttd for ttttndtnct, full ptymtnt thould bt potHitrktd 
by July 31. 1992 tnd rtctlvtd In tht Rtvtnut Offlct by Augutt 6, 1992. If your ttUmtttd 
•Wtrd/tld txcttdt you? account btltnct * peymtnt It not rtqulrtd. Tht top portion of tht 
tttttmtnt mutt bt ttlurntd to requttt v elide don. Student* with crtdftt In Meat* of chtr get 
mey pick up * check for tht diffartnet tt tht Rtvtnut Offlct tfttr Stpttmbtf 1, 1992. 



Tht ttmplt ttudent ttttement in figure 12 rtflecti til chtrget incurred trtd creditt 
received imce the Itit time tht itudtnt wit tent t sttternent. Tht top portion is retu'ntd 
with the ptyment tnd reflect! that portion of tht ttudsntt chtrget which tre immediately due 
upon receipt. Although chtrgea for future temeslert mty htvt been incurred, thty tre not 
required to be ptid until tht firtt billing cycle of ■ oemosttr. The bottom portion it t free 
text tret tnd mty be uttd for tptcitl mttruction. 
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INTERFACES 



As mentioned previously, charges are entered on-line by each area of responsibility. 
There are, however, times when the volume is so great that it was much more advantaoeous 
to develop an interface which would automatically upload data to the student's account. On 
a daily basis, we now upload all student parking fines issued for the day from a PC based 
system called TICKETTRAC. Library fines are also uploaded from the NOTIS system to the 
revenue fee credit system. On a monthly basis, telephone charges (one per student) are 
uploaded and posted to the student's account. (The detailed statement sent to the student 
is generated from a PC based system from COMPCO, uploaded to the mainframe and then 
printed on the mainframe.) The total amount is then posted to the student's account and is 
billed utilizing the new billing format implemented in July. Residential Life also uploads housing 
contracts (charges) once per semester. 

Periodically, Central automatically removes students from their enrollment for one reason 
or another, typically for non-payment or non-validation. When this is done the proper credits 
are generated to the student. Following any batch processing which might affect a student's 
credits, a batch credit adjustment program is run to process the student records to insure that 
all credits are adjusted to the proper amounts, (ie. PELL, Regents, etc.). 

The interface to CUFS (accounting system) is run daily during off-hours for all payments 
receipted, and then again after each application of credits. At this time the distribution is made 
from the appropriate credit accounts (PELL, Perkins, Voc. Rehab., etc.) to the appropriate 
revenue, expense and/or balance sheet accounts. 



REPORTS 

There are a variety of reports within the new credit system. Daily the student monies 
received will be reported in a revenue ledger. All documents generated within the interface to 
CUFS will be reflected in a daily document report. Also, an exception report of all checks 
issued to someone other than the student will be printed and reviewed. On a monthly basis 
a report is produced for all checks issued by the "overridr" operators. And, on-request, a 
variety of reports concerning credit available and balance of student's accounts are available. 

IN SUMMARY 

Much programming was accomplished in very little time, but not without a great number 
of hours of work by the programming staff at Central. We have, however, made many 
significant gains for many areas on campus. Some of the benefits of this system are listed 
below: 

1 . There are NO student financial aid, refund, or cash advance checks written in batch 
processing, virtually eliminating the large number of voided checks. 

2. There are no signed checks sitting around waiting to be misplaced. 

3. Funds are no longer taken from CMSU accounts until the on-demand check is cut. 

4. All credit adjustments are made automatically on-line allowing operator's to have an 
accurate view of the student's account at any time. 

5. The possibility of overawarding is virtually eliminated because it no longer requires 
manual adjustments. 
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6. The system allows pre-payment by students before charges are incurred. 

7. Specific credits (ie. parking) pay charges of the same type using the priority and order 
of application tabids. 

8. Student cash credits are applied to oldest charge first, thus clearing and improving the 
accuracy of the aging report. 

9. Less paperwork - Payment vouchers no longer necessary for issuing refund checks. 

1 0. Refund data is entered by area authorizing refund, thus eliminating disbursements data 
entry by accounts payable staff. 

1 1 . Better audit practice because of the enhanced security which has been built into the 
system, 

12. Greatly reduced the number of refunds necessary each semester. Application of 
credit not made until end of refund period. 

13. Sufficient records are available on-line to enable operator to track adjustment history 
of third party, fee and cash credits allowing for a much better audit trail. 

14. Aids in reducing the receivables - The opportunity is there to collect on all student's 
receivable prior to allowing a cash advance on remainder of credit available. 

15. Tighter security. 

16. As disbursements are made each student signs on the check stub, which is retained 
in the accounting area for control and issuance of duplicator., if necessary. 

17. Reduces the number of checks written because refunds for housing deposits, parking 
permits, returned books, and fees are all posted to the student's account and ono 
check can be written rather than one check for each refund type. 
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INTRODUCTION 

Arizona State University continually strives to provide 
secure, convenient and quality student services. More than 90 
percent of our 43,000+ students commute to either the ASU Main 
campus in Tempe or to the ASU West campus in Phoenix. To 
better serve this large student population, ASU has 
successfully integrated touch-tone telephone, voice response 
and computer technologies. The resulting system is InTouch, 
ASU's Interactive Voice Response (IVR) Registration and Fee 
Payment System. 

The required entry of a Personal Identification Number 
(PIN) helps insure a secure access method to InTouch. A PIN 
assists in: 1) Authenticating the identity of the caller; 2) 
preventing unauthorized access to student information; 3) 
insuring privacy of student data. 



HARDWARE/ SOFTWARE CONFIGURATION 

The InTouch system consists of two Syntellect, Inc. 
Emperor cabinets housing a total of 120 telephone lines. 
Terminal connection is through an IBM 3745 controller to a 
mainframe IBM 3090 500E host computer. The Student 
Information System (SIS) database was developed in-house in 
1980, using the IDMS database management system. The on-line 
registration and fee payment systems are programmed in COBOL 
and COBOL II using the IDMS/DC Teleprocessing Monitor. In 
1990, the PIN on-line screens were programmed in ADS/0. 

The mainframe PIN application communicates between a 
caller on a telephone and the SIS database using the IVR as an 
interface. The application has three components: 1) 
Verifying caller's identity? 2) changing student PINs if 
needed; 3) logging data items and tracking PIN activity. 



INTOUCH PILOTS 



Less than 10 percent of the students began using InTouch 
in a short, three week pilot in the fall of 1990 for spring 
1991 registration. The second pilot was conducted the 
following semester and ran for three months. During the 
second pilot InTouch was available to about 30 percent of our 
students. InTouch was available to all students fall 1991 for 
spring 1992 registration and fee payment. Initially used by 
students for class registration and drop/add, it has since 
been enhanced to include: 

class availability status 

♦ registration fee information 

♦ payment refund requests 

tuition fee payment via credit card, debit card and 
financial aid 

Post pilot reviews were conducted with the Registrar's 
Office, the Student Fee Payment Office and Computer Accounts 1 
Office (CAO) . The CAO is responsible for controlling access 
to ASU ! s mainframe computer systems. The Registrar ! s Office 
summarized feedback from staff., faculty and students. 
Feedback was very positive. The most often heard comments 
from students are how easy and convenient InTouch is to use. 

One issue that surfaced was unf amiliarity and confusion 
over entry of the PIN. An unexpected surprise was that most 
students did not know what PIN means. We made the assumption 
that students would have experience using bank cards at teller 
machines. We quickly learned most students have never been 
exposed to the concept of PINs. We changed the phone session 
to speak the phrase "Personal Identification Number" rather 
than the acronym "PIN". A phrase was added to tell the caller 
that changing the initial PIN on first use is a security 
measure. Another phrase explains a new password has to be 
entered twice to verify the correct number was keyed on the 
first attempt. Many callers did not perceive the PIN as a 
password. These changes, plus the fact students became aware 
that the PIN instructions were in the Schedule of Classes, 
have significantly reduced the number of calls for PIN 
assistance. Attachment A is a sample of the current script 
spoken to callers requesting entry of the ASU-ID and PIN. 
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ADMINISTERING PIN'S 



We researched information about PIN applications at other 
universities . A few universities reported using PINs, with 
few or no problems, A very conspicuous PIN, like the 
student ! s birth date, seemed to be used most often . 

At ASU, callers are requested to enter their nine digit 
ASU-ID number and their four digit PIN. Every students PIN 
is initially set to the month and day of their birth date in 
the SIS . Forced change of the initial PIN is used for added 
security. 

Business procedures before InTouch made walk-in photo 
identification an acceptable way of verifying student 
identification. A major goal of InTouch is to reduce student 
trips to campus. The student may be off campus, often out of 
state, when using InTouch. They may need quick resolution to 
PIN problems in order to get needed classes. Assisting 
students with forgotten PINs, PIN change requests and PIN 
related questions needed to be handled by phone as well as in 
person. 

A balance was found between convenience to students and 
legal/security issues. The primary consideration in 

administering PINs is to provide fast convenient service yet, 
maintain adequate safeguards against tampering and protect the 
privacy of student information. Great care should be taken to 
not reveal information about the student or a student's 
records to a caller, who may be an imposter. Enough questions 
must be asked to be convinced the correct student is on the 
phone. 

Because servicing PINs takes resources from whatever 
department is the administrator, it is important to keep the 
procedures fast and easy. ASU's PIN System is administered by 
both the Registrar's Office and the CAO. Figure 1 shows the 
screen used to assist students with questions or to reset PINs 
back to the initial PIN (birth date) . Each session to assist 
a student is logged as either an inquiry or a reset, but not 
both. There is only one incremental count for a given session 
with a student. The PIN is never displayed. The field "NEW 
PIN REQUIRED NEXT TTS ACCESS:" indicates whether the student 
is set-up for a forced PIN change their next call to InTouch, 
or if their existing (non-birth date) PIN must be entered. 
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RGTT110F TOUCH-TONE TELEPHONE SYSTEM (INTOUCH) 11/10/92 
LTERMID: CV200010 PIN CHANGE 13:03:58 



TASK: RGTT01 ID : 4 68-4 6-2005 USER OFFICE : REG (REG OR CAO) 

DIRECTORY RELEASE: 
NEW PIN REQUIRED NEXT TTS ACCESS: Y 



ID NUMBER: 468-46-2005 
NAME: SMITH , JOHN C 
LOCAL ADDRESS: 

74 0 EAST APACHE TRAIL 

UNIT 5 

TEMPE AZ 85026 

PERMANENT ADDRESS: 
10105 SEWARD HWY 
WESTFIELD NY 00034 
UNITED STATES 

LOCAL PHONE: 602-555-5555 

BIRTH DATE: 01-29-53 

ACTION: 

ENTER = STUDENT INFO 
PF5 = RESET PIN 
PF10 = PREVIOUS MENU 



LAST PREVIOUS INSTITUTION: 

NAME: ROLLINS UNIVERSITY 

STATE: MN 

LAST YYMM: 89 06 
HIGH SCHOOL: 

NAME: 

STATE : 

GRADUATION YEAR: 
RESIDENCY: NEW YORK 



LAST VALID TTS ACCESS: 08-25-92 



PF3 = PIN HISTORY 
PF6 = OVERRIDE DIR INFO 
PF11 = MAIN MENU PF12 = QUIT 



Figure 1. PIN inquiry and reset screen 



Individual student history of PIN transactions and resets 
are available on-line. Figure 2 is an example of the PIN 
CHANGE HISTORY screen for a student. The screen displays: 

the number of times a valid access was made with 
the student 1 s current PIN 

the number of times an invalid access has been 
attempted using the student's current PIN, since 
the last time a valid access was accomplished 

the date and time the student last made a valid 
access with their current PIN 

Whenever the CAO or Registrar's Office resets the 
student's PIN, the User-ID of the employee initiating the 



on-line transaction is logged. When the student calls InTouch 
and successfully enters his/her new (non-birth date) PIN , the 
system logs "STUDENT" as the person initiating the change. 
The reason for a PIN change is captured and designated by the 
following codes: 

11 C" - an ASU employee reset the PIN 

"I" - the student established a new (non-birth 
date) PIN for the first time 

nipt _ the student called InTouch and entered a new 
(non-birth date) PIN after their PIN had been reset 
by an employee 

When this screen is accessed, the inquiry history 
tracking count is incremented. If the PIN is reset, the 
inquiry count is reduced by one and the PIN reset count is 
incremented. Therefore, there is only one count for a session 
with a student. 



RGTT130F TOUCH-TONE TELEPHONE SYSTEM (INTOUCH) 11/10/92 
LTERMID: CV200010 PIN CHANGE HISTORY 13:07:18 

TASK:RGTT01 ID: 468-46-2005 USER OFFICE: REG (REG OR CAO) 

NEW PIN REQUIRED NEXT TTS ACCESS: Y 

ID NUMBER: 468-46-2005 LAST VALID ACCESS DATE: 08-25-92 
NAME: SMITH, JOHN C LAST VALID ACCESS TIME: 20:48:52 

INVALID ACCESS COUNT: 1 VALID ACCESS COUNT: 1 



MAINTENANCE 

USER OFFICE REASON DATE TIME 



KAEMS REG C 09-03-92 08:23:35 

STUDENT I 08-25-92 20:45:04 



ACTION: 

ENTER = NEXT STUDENT PF1 

PF8 = FWD PF9 

PF11 = MAIN MENU PF12 



PAGE: 0001 
= RESET PIN SCREEN PF7 = BACK 
= HELP PF10 = PREVIOUS MENU 

= QUIT 



Figure 2. PIN change history screen 



Summary history of PIN transactions is available on-line 
and on monthly reports. Figure 3 is an example PIN 
TRANSACT IONS BY DE PARTMENT report. The reporting period is 
the five most recent weeks. The total activity of those five 
weeks, the current month and the previous month are also 
reported. Inquires and resets are displayed separately for 
the Registrar's Office and CAO, and displayed as a combined 
office count. All information is reported real-time . This 
means whenever this screen is accessed or the report 
generated, the system calculates the reporting period based on 
the current date. Inquiry and reset counts in the SIS, at the 
time, are reported. 



CONCLUSION 

For added security to your Voice Response System 
applications, use Personal Identification Numbers along with 
student identification numbers or social security numbers. 
Administering and managing the PINs can be quick and easy if 
you set-up an on-line system to assist your staff in handling 
various questions and problems that may arise. 

There have been no security problems with ASU 1 s approach 
of initially setting each student's PIN to their birth date. 
We recommend not tying the PIN to any other process or 
requirement such as issuing the student's PIN when they 
complete advisement. When the advisement rules/process 
change, it can have a negative affect on your PIN process. 
Keep the PIN process simple, safe and convenient! Your 
institution's staff, faulty and students will be very 
grateful 1 
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Finding a Better Way: 
Implementing the Exchange of Electronic Transcrip ts 



Gloria Andrus 
Registrar 



Jerald D. Bracken 
Project Manager 
Brigham Young University 



Ricks College 
Administration Building 

Ricks College 
Rexburg, ID 83460-4125 

(208) 356-1007 



B-280 ASB BYU 
Provo, UT 84602 
(801) 378-7132 
Internet:JDB@ ARLAN.BYU.EDU 



In the fall of 1991, Ricks College and Brigham Young University (BYU) began 
discussing the exchange of electronic transcripts. In this paper we will describe the 
implementation of the AACRAO supported format for exchanging transcripts. We will also 
discuss the costs and benefits of electronic transcripts, as well as the major issues and problems 
we encountered. 



Paper transcripts create a number of problems. Your experiences with them may be 
similar to ours. 

Timing, The View From Ricks College 

Ricks College, as the kid sister to Brigham Young University, sends between 1800 and 
2000 transcripts to BYU each year. In the past, this procedure was very frustrating. That 
frustration intensified during the summer months as students attempted to meet the transfer 
admission deadline. 

The biggest problem occurred primarily when the applicant's official transcript from 
Ricks College arrived at BYU before the application did. BYU data entry clerks did not know 
which semester the student was applying for, so they placed the transcript in a holding file to 
wait for the application. In addition to this missing information, BYU did not want to incur the 
cost of data entering a transcript for someone who was not going to apply. After the application 
was received, the transcript was not always retrieved from the holding file and attached to the 
application for data entry. The result was the student was sent a letter stating that the transcript 
had not been received from Ricks College. The transcript clerk at Ricks would then receive an 
unfriendly call from the student (or the student's parent) wanting to know why the transcript had 
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not been mailed to BYU. The problem would only be resolved after the Registrar called the 
Admissions Office at BYU and asked that they look again in the holding file for the hard copy 
transcript. Invariably, the missing transcript would eventually be found. But, to reach closure, 
three or four long distance phone calls were necessary. The Registrar at Ricks spent hours each 
summer defending procedures, office efficiency, and resolving these problems. 



Lost and Misplaced Transcripts 

When things get hectic, especially around application deadlines, it is surprisingly easy 
to misfile, misplace, or lose a transcript. 

Labor Intensive Data Entry 

Data entry of transcripts is expensive. At BYU, we figure that a data entry clerk can 
enter about 70 transcripts a day. That works out to be about eight an hour. We receive 
approxiamtely 20,000 transcripts each year. That represents about 2,500 hours of data entry 
time. 



Data Entry Errors 

Because data entry is so labor intensive, errors occur. At BYU, we estimated that a good 
data entry clerk will make a keying error on only 2 percent of the lines entered. However, 
because of the line item structure of transcripts, error rates become more of a problem. Using 
the 2 percent error rate on a 15 class transcript, for example, the chances of that transcript 
having some form of keying error rises to 26%. Each keying error may or may not be 
significant. To catch and correct these errors, as well as to extend a courtesy to the applicant, 
we send an advisement report showing how the transferred work contributes to a degree at BYU. 
If the student discovers an error on this report, we get a call, the hard copy transcript is pulled 
from the student's file, and the correction is made. Errors, even small ones, cost money. 



Printing, Handling, and Mailing 

As part of a pilot project, Information Associates (now part of SCT, Inc.) estimated that 
the printing and handling of a transcript cost about $5.00. This agrees with our experience as 
well. That means it costs Ricks College $10,000 to send BYU those 2,000 transcripts annually. 
That is a significant amount of change. 



13.1 



Problems of Delayed Data Entry 



Transcripts do not come in evenly throughout the year. Transcripts bunch up 
dramatically around deadlines. The result is that at times BYU could be several weeks (or 
more) behind in entering transcripts. This causes several problems. First, the student does not 
know what is happening. So, the student begins a series of telephone calls, mostly long distance, 
trying to determine what the delay might be. A search is made for the student's file. This 
increases the work load on the Admission Office staff at a critical time. When the transcript is 
found, it is pulled out of the normal flow of operations, which creates the second problem. 
Whenever a transcript is dealt with outside normal procedures, the chances of that file being 
misplaced or lost increases significantly. The final problem is this. Does the transcript in 
question get expedited or does it go to the bottom of the stack? More often than not, it went 
to the bottom of the stack, further delaying its input. 

Obviously, with these problems we needed a better way. 



A Better Way 

As early as four or five years ago, Ricks and BYU began talking about the possibility 
of transmitting official transcripts electronically. One approach was tried with mixed results. 
Ricks would send a tape once a semester with a variable length record for each student. BYU 
would then try to produce an advisement report from this tape. This procedure had a number 
of weaknesses. The result was that we were all nervous about a "proprietary" solution. We just 
had to wait for the standards and technology to catch up with our desires. 

In November 1991, representatives from the BYU Admissions Office and computer staff 
went to Ricks to discuss the new AACRAO format for exchanging transcripts. That standard 
was in the process of being approved by A , >I, and it appeared that it would provide the means 
to finally address electronic transcripts. We hammered out many issues related to the timing of 
transmissions, transmission platfonns, translation software, data elements, etc. We will discuss 
some of these issues in more detail later in this paper. 

Our main goals were, first, to speed up the transmission of transcripts. That would 
relieve student anxiety. And in doing that, we would reduce the number of problem phone calls 
which were putting an unnecessary burden on our offices at critical times. The second goal was 
to avoid lost, misfiled, and unmatched holding file transcripts. The third was to reduce data 
entry errors. The reduction of handling costs v/as only a minor consideration for us. 

The first transmission was sent in June 1992. The summer of 1992 was wonderfully 
quiet in the Ricks Registrar's Office. No angry calls from BYU applicants. 
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Procedures 



The procedures for handling EDI (Electronic Data Interchange) transcripts are very 
simple. On the Ricks end this involves the following activities: 

1. A student comes to the transcript window and fills out a written request for an 
official transcript to be sent to BYU. 

2. The transcript clerk keys in the student's ID number and a screen appears, asking 
if the student wants the transcript to be sent electronically or wants a hard copy 
printed. (At the present time, Ricks is doing EDI transcripts only with BYU. 
However, Ricks is planning to expand this service as soon as the other schools 
get the technology in place.) 

3. Each Monday morning, the Registrar selects a menu item which extracts all 
transcript requests going to BYU keyed in since the last transmission. When that 
program completes, the Registrar gets a report of all transcripts included in the 
extract. The extracted file is then sent to a PC to be translated by Supply Tech's 
EDI translation software to the AACRAO approved format and transmitted to 
BYU. Figure 1 in the Appendix shows how this communication process works. 

Once the transmission has been received at BYU, Supply Tech's software package 
translates the AACRAO format to the format used at BYU. Figure 2 in the Appendix shows 
the steps involved in running Supply Tech's EDI translation software. 

The translated file is then sent to the mainframe and a program is run to update the 
student's records. The update program produces a list of all students in that transmission and 
a list of transcripts that still require the intervention of a terminal operator or evaluator. There 
are two types of problems which require intervention. The first occurs when a class has no 
matching evaluation record. This means there is not enough information to evaluate that class 
automatically. An evaluator examines the class, decides how to evaluate it, updates the student's 
records, and adds the evaluation information to the Evaluation File. This allows the class to be 
automatically evaluated the next time it appears on a transcript. 

The second problem occurs when the student can not be positively identified. For 
example, when Ricks sends BYU a transcript for a student who does not have a social security 
number, Ricks uses their local identification number. Therefore at BYU, we have no way to 
match up the transcript with a student at BYU. Another example occurs when last names do not 
match. Is the transcript really being sent for the same person? More often than not, the 
problem is nothing more than a name change resulting from a marriage. But, which name is 
the right one? In both these examples, a terminal operator must intervene before the transcript 
updates the student's records. We handle this by writing these transcripts to a Suspense File. 
The operator looks at the Suspense File, resolves the problem, and then re-applies the transcript 
to the student's records. Figure 3 in the Appendix shows the Suspense File process. 
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Issues and Problems Encountered 

During the design phase of this project, we wrestled with a number of issues and 
problems. 



Learning Curve 

The world of electronic documents introduced us to a whole new set of vocabulary and 
concepts. Electronic Data Interchange (EDI) refers to a set of standards for electronically 
transmitting documents. The AACRAO transcript format was also an ANSI (American National 
Standards Institute) approved EDI document, subject to the same rules and conventions as other 
EDI documents. Concepts such as transaction sets, segments, elements, etc. had to be digested. 

In addition to this, we found we had to build or bring together knowledge and expertise 
from a number of diverse areas: 

1. Networking - Internet, communication protocols (TCP/IP, etc.), Value Added 
Networks (VAN's), etc. 

2. Local Area Networks (LAN's). 

3. PC's. 

4. Mainframe communications. 

5. Student records application software, data base design, interfaces, etc. 

6. EDI translation software packages. 

Choosing a Communication Platform 

One of the first decisions we had to make was which communication platform we were 
going to use. We identified four reasonable alternatives: 

1. A direct connection over a phone line between Ricks and BYU, i.e. modem to 
modem. 

2. A tape or diskette exchange through the mails, i.e. a sneaker net. 

3. A Value Added Network (VAN), i.e. a commercial network like IBM's, G.E. 's, 
British Telcom, etc 
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4. The Internet. 



We chose to use the Internet for the following reasons: 

1. Most colleges and universities already have Internet access. 

2. Internet access represents a fixed cost to these institutions that has already been 
covered. This means the marginal cost of using the Internet for EDI transcripts 
is near zero. On the other hand consider the cost of a Value Added Network. A 
VAN typically charges 50 cents per 1,000 characters transmitted. The average 
EDI transcript from Ricks consists of 1,500 characters. An average batch of 70 
transcripts,then, would cost $105. It would be cheaper to put the transcripts on 
a diskette and express mail it. 

3. The Internet is very fast. 1 .5 million bits per second and 51,000 bits per second 
are common transmission speeds, with some links as high as 45 million bits per 
second. Even a large batch of 1,000 transcripts could be transmitted in seconds 
as opposed to hours using a modem connected to a VAN. 

4. The Internet is very reliable. 

5. The Internet is quite secure. Unlike the old BITNET, which was a "store and 
forward" network, Internet is a "packet switched" network using physically 
secured routers instead of users' computers to forward transmissions. It would 
be very difficult to intercept, modify, or create a bogus transcript transmission 
on the Internet without its being detected. 



Buy or Build 

The next most important decision was whether to write the translation software ourselves 
or to buy an EDI translation software package. After reviewing the EDI transcript standards and 
rules, we concluded that coding the communication handling, translating, cross reference tables, 
etc. was possible, but not easy. Also, the maintenance 'ost of such complex code would be 
high. But most important, what would we do as we added more and more EDI documents. The 
Purchasing Office at BYU had also expressed interest in using EDI technology. Why should 
they have to re-invent the wheel? For us purchasing EDI translation software was the best 
choice. We chose STX from Supply Tech, Inc. for the following reasons: 

1. They were willing to develop and support an Internet capability. 

2. They were experienced and had a large customer base. 




3. They supported many different communication platforms, i.e. all VAN's, 
direct connections, tape and diskette exchange, as well as Internet. We could use 
the same software package regardless of the communication platforms we 
negotiated with other trading partners or EDI documents. 

4. They were one of the few EDI software vendors which supported the EDI 
transcript transaction sets at the time. 



Design Decisions 

We also struggled through some important design issues. First, should we do a class-for- 
class update of a student's transcript work? Or, would it be more appropriate to delete the old 
transcript and replace it with the new one. The decision rested on our ability to automatically 
re-evaluate the student's transcript and get the same answer. We were confident that our 
automatic evaluation could re-evaluate the transcript with few errors or little need for operator 
intervention. This decision made the update program much simpler. It would assume that the 
new transcript was complete and accurate. So, it did not have to check for repeats, grade 
changes, missing classes, etc. 

Second, although the EDI transcript had a standard format, we examined every data item 
in that standard to make sure we all inteipreted the data values the same. Some of these 
required a little negotiation. For example, there is room for a student's address to be sent. 
Which address should that be, mailing address, or home address. Just exactly what does each 
grade mean? The A's, B's, C's are obvious. But, what about pass-fail, credit by exam, 
withdrawals, grades not submitted, repeats, etc.? 

Third, we found one important piece of information missing from the EDI transcript. 
Often the transcript is the first document received in the admission application process. It would 
be very helpful if the EDI transcript indicated whether the transcript was being sent as part of 
an application, and if so, indicate which year and term the student was applying for. We 
decided this was important enough in the relationship between BYU and Ricks that this 
information would be coded in a note segment. Even though this feature was not recommended 
by the AACRAO committee which developed the standard, we felt the benefits outweighed the 
risks. 



Was It Worth the Effort 

We were confident this technology would be a benefit to both BYU and Ricks in many 
ways. We were correct - and it is even better than we anticipated. Not one angry student 
called this past summer. Table 1 shows the cost Ricks and BYU incurred as of this writing. 
Table 2 shows the cost savings we realized. 
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Table 1 
Cost of EDI Transcripts 

Up Front Cost: 

$5,000 2 copies Supply Tech's STX package 

7 person months Analysis, design, learning curve, 

programming, software selection, training, 
negotiation, etc. 

On Going Costs: 

$1,200 per year Software maintenance 



Table 2 

Cost Savings of EDI Transcripts 
1,000 Transcripts Received to date 



$290 Postage 

$5,000 Handling ($5 per transcript, SCT, Inc.) 

$1,200 Data Entry (15 person days) 

$6,490 Total savings 

$18, 000 Projected Savings per year 



These tables show that moving to an EDI transcript has clearly been worth the effort. 

In addition, the speed of getting the transcript from Ricks to BYU with no lost or 
misplaced transcripts has greatly reduced the hidden costs of dealing with hard copy transcripts. 

As a result of these benefits, the President's Staff at Ricks College approved a proposal 
to cancel the transcript fee for any transcript sent via EDI effective January, 1993. 
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Future Plans 

We plan to expand the EDI concept in the following ways: 

1. Transmitting transcripts from BYU to Ricks. 

2. Exchanging EDI transcripts with other colleges and universities. 

3. Incorporating additional EDI documents, for example, admission applications, 
financial aid transcripts, verification of enrollment, etc. 
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STX Description 



FTP EDI 
Transcript 



H:\STX 



RICKSFELBYU 
UVCCFIL.BYU 
PROVOFELBYU 



H:\STX 



Temporary file 

Functional 
Acknowledgements 



H:\STX 



DX-XF-VF.080 



Mainframe 



Run Update Job^ 



Ricks 
College 




uvcc 




Provo 
School 
District 




• • • 



STX Receive 

1. Copies all \byu 

2. Examines all 
Transactions 

3. Generates 
Functional 

Acknowledgements 





FTP Fiat File 
to Mainframe 



Reports 

ERiC 




STX Send 
Functional 
Acknowledgments 



STX Archive 
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Suspense File Concept 
September 3, 1992 



EDI 
Transcripts 




Mainframe 



Functional 
Acknowledgements 




US2043ED 

If LAST-NAMES 
do not match 
OR 

If LOCAL-ID 
supplied 

Build Suspense 
File 



TP Program A23(?) 



Lists problel&s by College 

Code and Transaction ID. 
Displays name, ID Num, 
Date Received, Problem 
Type, and Action Flag. 
Entries tied to Alpha Xref. 
Allow changes to name and 

ID Num. 
PF Key submits Update Job. 



t: 



Update Job 



Tap Program taps and deletes all Suspense 
Records with ACTION-FLAG * T', deletes 
all records with ACTION-FLAG = 'D\ and 
deletes all records older than X days. 

Run US2043ID again. 



Suspense File 



Key: 

UNIV-COLL-CODE 
TRANSACTION-ID 
SEQUENCE-NUM 

Rest of EDI Flat Record: 

(80 Characters) 
Positions 54 & 55 of 
«STX12» Record 

contain: 
PROBLEM-TYPE 

L » Local ID Number 

N = Mismatched Name 
ACTION-FLAG 

D = Delete 

H = Hold 

P = Process 
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Moving Toward a Paperless Workplace at The University of Michigan 



Karen Dickinson 
Systems Development 
Coordinator 



Patrick McCormick 
Systems Development 
Coordinator 



The EDOCS Subgroup* 



The University of Michigan 
Ann Arbor, MI 48104-3799 
(313)763-0107 
karen.dickinson@um.cc.umich.edu 



"Sixty-five cents of every dollar spent on record-keeping is wasted on 
■unnecessary files and duplicate copies," said Dianna Booher, in an article 
entitled, "Cutting Paperwork in the Corporate Culture" (Facts on File, 1986). 

"By bringing design and production of forms in-house, companies can save 
more than 70%.... The drive to get electronic forms off of large systems and 
onto personal computer platforms may shrink costs even more. But saving 
money isn't the real benefit of forms automation. Through the use of 
workgroup automation and client /server, enterprise-wide connectivity, firms 
are improving the quality and efficiency of their operations because users get a 
palatable interface to enterprise data. " said Michael Bragen, in an article 
entitled "Form Fitting" (Computerworld, September, 1992). 

Introduction 

Replacing paper documents with the capability to prepare and process 
documents electronically at the desktop workstation has long been a high priority 
issue at The University of Michigan (U-M). Progress toward a paperless workplace 
has been slow, because of the many surrounding issues including legal 
implications, a highly heterogeneous computing environment, and the amount of 
resources involved. An Electronic Documents (EDOCS) group was formed this 
spring to determine the best way to build on earlier efforts, to provide direction for 
various ongoing campus initiatives, and to develop a plan for the most effective 
and efficient processing of business transactions for the University community. 
This report defines the first phase of the migration to a paperless workplace at U-M 
and includes a blueprint for future phases. 



*The other EDOCS Subgroup members: John Gohsman (Chair), Chuck Hawkins, 
Jim Peters, and Dick Albertson. 
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Background 

U-M's decentralized and heterogeneous nature increases the magnitude and 
complexity of the security, political, and technical issues. U-M is a classic 
"multiversity". It has seventeen schools and colleges on the Ann Arbor campus 
and two regional campuses in Dearborn and Flint. Although one Board of 
Regents and one President oversees all, each department has its own policies and 
standards. On the Ann Arbor Campus, some functions are performed centrally, 
such as registration and student accounting; others, including admissions and 
financial aid activities, are performed both centrally and by departments. Still 
others are done solely by departments, including academic advising and 
certification of degree requirements. 

Computing is already quite distributed, with an estimated 20,000 personal 
computers being used in offices, campus computing sites, residence halls, and in 
remote locations. Many staff and students perform their work from varied 
locations, including dialing in from home Throughout the campus, thousands of 
computers linked to state-of-the-art networks provide faculty, staff and students 
with resources that can maximize creating, using, and sharing information. Many 
of the larger departments, such as the College of Engineering and Business and 
Finance, are at the forefront of rapid advances in information technology; other 
departments are on a computer hardware replacement cycle of seven or more 
years. 

Many departments also share information and send mail on local area 
networks (LANs), with Banyan and Novell being major campus presences. Other 
departments are operating primarily in standalone mode or connecting to one of 
three mainframe hosts on the Ann Arbor campus. There are multiple mail 
systems; these include a homegrown mainframe mail system (MTS $Message), 
Microsoft Mail, Lotus CC:Mail, and various UNIX mail packages in the public 
domain. All this is consistent with U-M's philosophy that diversity should be 
encouraged on all levels and that departments should be able to control their own 
destinies. However, this philosophy compounds the problems of migrating to 
electronic documents. 

To add to the complexity, the computer environment at U-M, as in the 
country at large, is in a period of transition from centralized, mainframe-based 
computing to fully decentralized computing. We are moving toward an 
environment that is centralized from the user's viewpoint, focused on the 
workstation, and tailored to specific user needs. A key U-M goal for migration to 
electronic documents is a smooth, phased transition of users from host-based e-mail 
systems to fully distributed e-mail within three years, since e-mail will be the 
transport for routing electronic documents. 
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The potential for tremendous savings has sparked several significant efforts 
to migrate toward electronic documents despite the barriers* 



• The Electronic Document Handling System (EDHS), designed at U-M in the late 
'80s, defined many of the benefits of and requirements for an electronic business 
transaction environment. Three successful electronic document systems were 
implemented as IMS transactions in the 1980s. The University Stores 
Requisition System was implemented as a prototype in 1984. This system was 
the springboard for designing a more comprehensive electronic documents 
system* Users and developers were enthusiastic about the potential for electronic 
documents, but needed a quicker method to develop them. The EDHS project 
produced a Project Definition and a General Systems Design. Two other 
documents, the Food Stores Requisition and the Purchase Requisition, were 
developed and implemented under the EDHS umbrella. The effort was finally 
tabled, since a mainframe solution didn't appear to be cost-effective. 

• Uniform File Formats (UFF): in response to user requests, Financial Operations 
has invested significant resources in exploring uniform file formats to introduce 
nine statement of account transactions into central administrative systems in a 
standardized way. Some users created forms using local software, such as Excel 
and dBASE, and wanted to have these entered electronically into the system 
instead of printed on forms for subsequent keypunching. Two forms, cash 
receipts and journal entries, were followed to their final format in application 
programs. The analysis showed that most business transactions were in the 
same electronic format despite the fact that the paper forms were different. The 
UFF project has already saved approximately two weeks of manual processing 
each month. The project has also spawned projects for other transactions, such 
as producing service unit billings and downloading credit card information and 
lock box information from online bank systems* Once information is put into 
standard, electronic media, it will be easier to adapt to the ever-changing 
technical environment. 

• The External Electronic Data Interchange (EDI) Project : U-M is improving its 
Purchasing and Accounts Payable system to better handle the annual volume of 
130,000 purchase orders and 430,000 invoices. Purchase order files will be 
downloaded daily from the mainframe to an EDI server, then transmitted over 
the Internet network to a value-added network (VAN). The VAN has 
"mailboxes" on a computer system provided by a third party vendor. EDI 
transmissions of invoices, acknowledgments, and responses to request for 
quotations will also be available over the Internet and uploaded to the 
mainframe. 
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• The College of Engineering's Computer Assisted Engineering Network (CAEN) 
developed a Claris FileMaker system that facilitated electronic filling of about 
fifty common U-M forms for Macintosh users. This system was developed by 
CAEN primarily for Engineering's own use and some maintenance difficulties 
resulted surrounding obsolete versions of forms, since form owners weren't 
directly involved. CAEN offered to share the system with other U-M 
departments and about 50 departments now subscribe. DOS users wanted a 
similar system, and a DOS Electronic Forms pilot was undertaken. This pilot 
team is a partnership of twenty-five U-M departments, including forms owners 
and the Information Technology Division (ITD). 

The DOS Electronic Forms Pilot 

The DOS Electronic Forms pilot was intended to reduce the amount of effort 
in producing common U-M printed forms by enabling them to be entered online 
via microcomputer. Other important goals of the pilot were to provide information 
needed to resolve some of the issues surrounding elimination of paper forms, 
including the amount of support required, without diverting extensive resources 
from the larger task of eliminating paper forms. 

There is general agreement that the real benefit will come from re- 
engineering processes and optimizing electronic transmission of forms-moving 
beyond the paper model and redundant processes. Eliminating paper forms was 
beyond the scope of the pilot, since important issues, such as authentication and 
security, need to be resolved before printing can be eliminated. 

Benefits of the pilot included: 

Saving time: 

• Errors easily corrected and caught earlier. 

• Repetitive information extracted from previous or related forms or 
departmental databases to fill in new forms. 

• More accurate information due to automatic calculation of fields, edit capabilities 
(including required fields), possible field validation. 

• Faster information retrieval-existing records and departmental databases could 
be queried. 

• Reduced or eliminated the need to order forms. 

• Facilitated easy distribution of forms. 

• Eliminated bottlenecks that caused key deadlines to be missed. 
Saving paper: 

• Eliminated need to stock blank forms (especially cost-effective with expensive 
multi-part forms). 

• Eliminated storing hard copy of forms (if office procedures permit). 

• Eliminated obsolete/unusable forms. 
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Better record keeping: 

• Data files produced from the forms package were used to do office accounts. 

• Standardization and improved quality of the process. 

The pilot provided a subset of forms to DOS users in PerForm Pro by Delrina 
Technology. PerForm Pro was selected since it was highly rated in the trade 
journals, met all the important criteria defined by a U-M Forms Evaluation Team, il 
interfaced with dBASE files, a rigorous pilot could be conducted at a reasonable cost, 
and the software was affordable. Collaboration with forms owners was viewed as 
critical; all forms were reviewed by the office that owned the forms for accuracy 
before distribution. 

Pilot Results 

Filling forms with the Windows and DOS GLM product worked well (the 
DOS GEM version has a graphical interface that looks to the filler like the Windows 
filler version). However, pilot participants needed a 386 machine or higher for 
acceptable response time which would be expected for an application of PerForm's 
power and complexity. However, the participants that were interested in using the 
GEM product had lower-end machines and found the slow response time a barrier 
to using the product. Results reported by forms fillers include: 

• Using the filler software cuts forms filling approximately in half (which could be 
one or two hours a day for typical administrative staff). 

• Printing requires 1 megabyte of RAM, more than a typical secretary's 
configuration, and getting printers configured correctly was tricky. 

• WYSIWIG (actual representation of the form on the screen for filling) may 
detract from the process if forms are difficult to read. Using a different form for 
data entry may make sense and text-based forms may be acceptable if the 
functionality exists. 

• There were some printing problems that the new version of PerForm Pro 2.0 for 
Windows has fixed. 

Delrina's PerForm Designer and Tracer products for designing and converting 
forms into electronic format also worked well for people familiar with Windows. 
PerForm Designer's wide range of features and options facilitate forms design, 
including spreadsheet capabilities, drawing tools, and the ability to read and update 
dBASE files and graphics. PerForm Tracer accepts a scanned image, aligns lines and 
boxes, and interprets some relationships between fields defined by lines, such as 
fields to be summed. Results reported by designers include: 
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• Since the application has many features and options, the learning curve for 
Designer is high and wouldn't be justified for most offices. Several forms 
owners said they would rather hire ITD to do the basic forms design, although 
they did want to make minor changes to their forms. The Department for 
Research Development Administration (DRDA) has very complex forms that 
change frequently, and they may develop in-house expertise once a decision is 
made about supporting the forms software. 

• Using Tracer cuts designer time about 1-1/2 hours (more on forms that have 
mostly lines/boxes; on forms that are mostly text, Tracer is less useful). 

Both forms fillers and designers were asked to evaluate how well the 
proposed process meets U-M needs. Reported results include: 

• Potential for Significant Savings . Most pilot filler participants who were 
familiar with Windows and had model 386 or higher machines (designers 
and fillers) found it worth the effort to convert to electronic forms. 
Automatic searching, storing and filling repeated of already stored fields 
significantly increases the speed and reliability of forms filling. The ability 
to read and write dBA.SE files and a programming language behind the 
process may make PerForm more attractive than other alternatives, such 
as FileMaker Pro 2.0 for Windows, but this needs to be verified. The ability 
to have edits and mandatory fields significantly increased the reliability of 
forms filling and saved time in redundant entry and resolving errors. 

• Electronic Routing . Delrina's products have the ability to electronically 
send forms, and have security and authentication features. Even in the 
short term, it may be possible to do some electronic routing of forms, 
which is where true savings accrue. What needs to be tested is whether 
the products can be integrated into the U-M computing environment, 
with its dissimilar LANs and mail systems, and how much effort would be 
required. 

• Support Concerns . Delrina's rapid growth resulted in changes in sales 
representatives and technical resources as territories were redefined 
during the pilot. This put a burden on some of our expert staff. Also, the 
education market is a new area for Delrina. Although several pilots are 
underway, they do not have a formal education program and this will 
make it harder to work with them. Recently, Delrina he .shown more 
commitment to U-M. Also, we anticipate an environment where ITD 
creates a fairly limited number forms and supports users filling forms, so 
vendor support is less critical than if ITD were attempting to support 
forms creators and a large number of forms. However, we do have 
concerns about vendor support. 
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• Other Key Results , It is important that this project fit into related efforts at 
U-M. It is critical to avoid the trap of simply automating the existing paper 
process if there is the potential for re-engineering the process. This 
technology is moving very fast. Any decision is likely to be viable for only 
1-2 years, so the investment must be recaptured within that timeframe 
(including training/retraining and other support costs). 

Pilot Recommendations 

The pilot demonstrated that the amount of efficiency that can be gained by 
targeting appropriate forms and users is significantly greater than the investment of 
converting the forms, acquiring the software, and training staff how to use 
electronic forms. However, problems with the product, particularly memory 
requirements and slow printing, along with reservations of key support personnel 
about the process suggested a cautious approach. Participants in the DOS Electronic 
Forms Pilot decided that they did not have enough information to make a 
recommendation to the U-M committee that determines which products will 
receive support and what services will be offered. Moreover, they thought that 
focusing on DOS/Windows alone was unwise. Therefore, pilot participants 
recommended: 

• The Electronic Forms Evaluation Team should consider alternatives in both the 
Macintosh and DOS environments. 

• The number of electronic forms (converted to the recommended software) and 
forms fillers should be gradually increased according to pre-defined criteria, so 
that the process is cost-effective and does not become unmanageable. 

• The process should be viewed as an interim solution that will be continually 
evaluated and replaced by a more desirable solution. Although some of the 
investment will probably be salvaged, it is important to recapture the investment 
within a short timeframe (1-2 years). 

The Electronic Documents (EDOCS) Project 

In addition to the DOS Electronic Forms Pilot, there are a number of 
significant ongoing efforts at U-M related to electronic document handling. The 
Electronic Documents (EDOCS) group formed during the spring of '92 to define a 
common vision and to develop a plan to establish the most effective and efficient 
processing of business transactions for the U-M community. 
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The EDOCS group agreed that minimum requirements for electronic 
documents include routing a document through channels; signed by appropriate 
people, with validation, authorization, and authentication; and filed for quick 
retrieval for reference or inspection by auditors. The following project goals were 
identified: 

• Build on the existing foundation of previous efforts and collectively reduce 
institutional costs. 

• Meet valid customer needs as long as a need is reasonable, achievable, 
legal, and ethical. 

• Provide a flexible system that can adapt to future needs and changes. 

• Provide the flexibility to use whatever terminal /software combinations 
users have to create and transmit electronic documents to other addresses 
on the network 

• Create an overall vision and strategy to provide a consistent and standard 
environment for the user community 

• Ensure that all projects related to migration toward electronic documents 
work to implement this vision do not perform redundant development 
efforts. 

Environment for Electronic Documents 

The computing environment for electronic documents has already been 
well defined by other U-M groups charged with defining the vision for a future 
computing environment. The EDOCS Group supports their vision and notes the 
following points as particularly relevant for electronic documents: 

• The environment will be distributed. Computing, instead of being 
concentrated on a mainframe computer, will give computer users desktop 
access to a broad range of computing and information system technologies, 
which could include mainframes. 

• Client-server software, rather than terminals, will be increasingly used to 
manipulate, view, and modify data. This will allow users to take advantage of 
the computational power available from desktop machines. 

• Certain services, such as mail and paperless documents, will still be handled 
centrally (e.g., forms will be stored in a central repository). 

• E-mail running on a reliable, high-speed, high-capacity Campus Backbone 
Network with support in place, will provide the transport. 
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• The environment must be secure, with authentication, auditability, and 
controls in place. 

• Commercially available software should be used as much as possible as well as 
University-enhanced software. 

• Evolving standards should be adopted, such as X.400, Multi-purpose Internet 
Mail Extension (MIME), Apple's Open Collaboration Environment (OCE), 
Microsoft's Messaging API (MAPI), and Vendor Independent Messaging (VIM). 

The EDOCS Group also supports the principles of Electronic Data 
Interchange (EDI). For many years, EDI has been providing companies with a 
method to exchange information electronically, from disparate systems. This low 
technology solution has provided many benefits to these companies, including 
quicker response, higher quality service, lower costs, and better information. 
Transactions typically exchanged between companies include purchase orders, 
invoices, and payments. Some universities are starting to use EDI to exchange 
transcript information. The EDOCS Subgroup has researched EDI technology and 
believes the same concepts, principles, and possibly the software itself, could be 
applied to the electronic document needs of U-M. In addition to the above 
environmental characteristics, EDI requires: 

• Trading P artner Agreements . A contract is made between two groups that want 
to conduct business electronically, agreeing to establish appropriate controls, 
standards and testing to ensure that the electronic information is correct, 
auditable, and approved. 

• Standards for each Transaction Type . Transaction types such as purchase 
requisitions, journal entries etc. will have the same fields in the same format 
and sequence and be consistent with the American National Standards 
Institute X.12 uniform standards for electronic interchange of business 
transactions 

• Translation software . Translation software provides a method to map, or 
translate, data from an application into the standard format and to take the 
standard format and map it back to an application. 

The Planning Process 

Effective planning is essential for an undertaking of this magnitude. 
Although there is tremendous potential for reducing effort, the inevitable change 
in customary, critical routines will also be disruptive. A coordinated, phased effort 
with active participation by affected parties will ameliorate the negative aspects of 
change. Fortunately, the climate for planned, gradual change is very favorable at 
U-M and there are several key methodologies in place to assist in the transition. 
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Efforts to Improve Quality at U-M 

M-Quality is a U-M priority initiative now underway to examine and better 
understand its administrative and business processes. The Information 
Technology Division (ITD) has been independently engaged in a Total Quality 
Management (TQM) initiative for the past two years; TQM provides 
methodologies for improving processes and sets the overall "Plan, Do, Check, Act" 
cycle for everything ITD does. 

A brief summary from the M-Quality report an initial planning document, 
states that the M-Quality approach will encourage positive change within U-M. 
Four key principles are the foundation for M-Quality: 

• Pursuing continuous improvement : studying administrative and business 
processes, making trial improvements and testing them, and revising them 
based upon further evaluation. The M-Quality approach is expected to evolve 
over time as U-M gains experience with it. 

• Manag in g by fact : making a distinct effort to gather and analyze relevant facts 
as a guide to decision making. 

• Respecting people and ideas: based on the assumption that the majority of 
difficulties in the workplace are caused by problems in the systems rather than 
the people who operate within these systems. 

• Satisfying those we serve : focusing on the recipients of the work. 

The report points to a three-part focus on leadership, teams, and 
individuals: 

• Planning for excellence : a set of leadership activities intended to clarify, 
reaffirm and communicate the mission and vision of the University and to 
bring policies and procedures into line with M-Quality principles. 

• Quality-improvement teams : designed to study and improve work processes. 
The EDOCs project is an example of an informal quality-improvement team. 

• Quality in daily activities : draws more fully on the potential of everyone 
within the organization by empowering individuals to use information to 
implement appropriate changes in how they do their work. 



ITD Planning Methodologies 



ITD has several planning methodologies in place that facilitate designing 
and implementing successful information technology systems: the ITD Planning 
Model, the ITD/University Information Systems (UIS) Systems Development 
Methodology, and the UIS Strategic Data Planning (SDP) process. Although 
developed independently, they share many of the same principles and also 
complement each other. 

• The Planning Model facilitates formulation of a project plan for addressing the 
need, developing and implementing the solution, and supporting and 
evaluating the results. Following the Planning Model contributes to 
ownership by the appropriate parts of the Division and ongoing commitment 
to the solution by adopting a cross-ITD, "whole system" perspective. It outlines 
steps and guidelines to pull together the right people to address the specified 
customer need, and further aids in producing the initial scope and charge for a 
system development project. 

• The SDM comes into play once the right people are gathered and charged 
appropriately to address the need. The SDM provides guidance in the pre- 
development stages, as the charge and scope of the project is further defined, 
and it also provides guidance in defining specific customer requirements and 
further definition for the solution. 

• Strategic Data Planning is a collaborative effort between ITD, Business and 
Finance and Academic Affairs. Strategic Data Planing is the establishment of a 
long term direction for the effective use of information resources. The U-M 
approach is based on James Martin's Information Strategic Planning. It will 
result in the creation of an institutional data architecture and an information 
systems plan. 

Other Factors Contributing to a Successful Migration 

Several factors for a successful migration to electronic documents emerged 
in a review of the literature and are consistent with U-M experience, U-M and ITD 
strategic directions, and the methodologies described above. 

• Analyze work flow to identify processes that need rethinking. The best kinds of 
forms systems are based on careful collaboration by information systems groups 
and key users to find out how many documents are in use and how those 
documents support tasks, 

• Use the e-mail infrastructure to cut duplicated effort. An existing mail system 
already resolves such issues as user addressing, message storage and routing, 
multiple client interfaces, gateways between dissimilar environments, and 
security. 
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• Maintain a centralized repository of important documents to ensure that 
electronic document exchange functions smoothly and accurately. 



• Implement electronic documents in small pilot projects, then tie them 
together; meanwhile, design solutions from the top down for a cohesive, long- 
term strategy. 

• Provide a corporate model that promotes data consistency and standardization 
and minimizes duplication in capturing, storing, and maintaining data. 

Project Recommendations 

A pilot project was proposed to last approximately one year. Pilot goals are 
to evaluate alternatives for electronic transmission (including routing), 
authentication, authorization and distribution; discover the level of coordination 
and facilitation that an electronic documents environment requires; and plan for 
the future. Concurrently, documents can be categorized by security level and 
volume. A proactive approach is strongly recommended for resolving security 
issues for more sensitive documents. Pilot results will provide information to aid 
in the creation of a long-term strategic and tactical plan for migrating toward 
electronic documents, including setting priorities for re-engineering processes. 

Following is a description of the three recommended alternatives for 
testing: 

Transmission/Routing/Distribution 

• Internal Electronic Data Interchange (EDI) (Supply Tech). 

Test the feasibility of using electronic data interchange (EDI) software and 
methods to exchange information electronically across disparate U-M systems. 
EDI has been widely used to transfer information between organizations, such 
as banks, but the same approach may be successful within departments of a 
heterogeneous organization, such as U-M. 

• Mail-enabled applications (e.g., Cc:Mail, Microsoft Mail). 

Test the feasibility of using a mail application to send documents entered and 
edited with PerForm or FileMaker Pro for Windows. Tracking of documents 
status would not be included, and there may be limitations on security features 
(authentication and encryption), particularly when documents travel between 
different mail systems, such as Microsoft Mail and Cc:Mail. 

• Group Communications Software (Lotus Notes) 

Test the feasibility of using Lotus Notes to enter, edit, encrypt, send or route to a 
pre-defined list, authenticate, approve if necessary, and track documents 
online. Lotus Notes has a limited forms creating capability and an imaging 
capability so that attachments, such as a memo, can accompany a document 
electronically. 
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Several documents have been suggested to test different aspects of the 
approaches. All processes are internal to the U-M, so under U-M's control. 

• Purchase requisition: used to place an order at U-M stores. The processes are 
fully defined and the form is a simple one. No cash is involved in the 
transaction. 

• Journal entry form: used to transfer dollars between accounts. It is a cash 
transaction, but since it is an internal U-M process the risk is less than if cash 
could leave U-M. The processes have been fully defined and the form is a 
simple one. Attachments may be required, such as receipts. 

• Course approval request form: describes a proposed new course or change to an 
existing course. It is an internal U-M document, the processes have been 
partially defined and plans are underway for fuller definition. Electronic 
routing would make a significant difference (it is an 6-part document). 

Financial Operations provided funding to evaluate the three methods on the 
journal entry form. 

Emerging Themes 

Several themes have emerged from the several projects currently underway: 

• Focus on the business rules and processes, not on the technology. It's important to 
design an automated process so that new more optimal technical solutions can be 
substituted transparently from the user's perspective when they become available. 
For example, we see sending and routing information around for approval 
separate from updating the institutional data repository; the two processes will be 
integrated, but not combined. 

• Re-engineer any process before automating it, taking advantage of the electronic 
medium and not being bound by the current paper design. It's important to 
realize that many processes can't be fully automated; partial gains with large 
volume can still yield significant benefits. For example, many personnel forms 
with stringent security requirements will still be printed out, signed and routed in 
traditional ways, but the data entry and edit portion of the process can be 
automated. 
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A single enterprise-wide solution appears unlikely in the foreseeable future. 
Offices vary in style, computing environment and technical sophistication. We 
prefer to select a few products that are industry leaders whose vendor's vision is 
consistent with the U-M strategic direction. It is also important that the vendor 
have the resources to implement the stated vision. We evaluate these products in 
the U-M environment, implement solutions using these products on a small 
scale, and offer the solutions as options to selected customers. For example, we 
agreed to try Lotus Notes on one form for one office: Financial Operations' journal 
entry form. Whether we offer it to other offices depends on Financial Operations' 
approval of the approach (as well as the approval of Internal Audit). 

Do minimal programming . Choosing vendor solutions that are fully developed 
and integrate smoothly into the environment, or those where the vendor is 
willing to work with us to integrate their products into our environment, frees us 
from excessive in-house development. For example, we will evaluate Delrina's 
FormFlow product, which is expected to be released this year and may facilitate 
forms routing and tracking, rather than write our own electronic "routing slip". If 
FormFlow cannot serve as an electronic routing slip in our environment, we will 
use Lotus Notes or some other vendor's technical solution even if it means 
delaying oar routing plans. 

Partnership with users is critical . Partnership with forms designers /receivers 
ensures accuracy and integrity of the process and allows us to offload the 
maintenance burden in some cases. Partnership with forms fillers ensures that 
the product meets their needs and enables us to offload some of the support 
burden if offices have internal technical support resources. 

Cost-payback must be achieved within about one year . Some pieces of pilot 
systems may be retained, or the pilot may continue despite "better" technical 
solutions if an office decides the costs outweigh the benefits. Each office should 
make the decision assuming that the system is essentially disposable within about 
one year. This is an area that causes us some concern. Once an office and their 
clientele become accustomed to a way of doing business, they may be unwilling to 
abandon it even in their own "best" interests. We intend to be clear at the outset 
with our customers about cost and risks and to let them decide. 
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• Partic ipation requires a fairly hieh-end computing environment; it is 
unrealistic to try to hit the lowest common denominator. Customers will need 
connectivity to the Campus Backbone and machines with sufficient power to 
run typical electronic forms applications (e.g., a Windows environment with a 
model 386 PC or higher with 4 megabytes of RAM and a recent model laser 
printer with sufficient memory to handle complex printing tasks). The U-M is 
committed to improving the computing infrastructure, but for the near future, 
our less affluent customers won't be able to fully participate in the benefits of 
these new technologies. Currently, we are working on solutions that work on 
Windows and Macintosh platforms. DOS products do not seem equal to the 
task, and there is not sufficient demand to invest resources in a UNIX solution. 

• Keep the future in mind . It is critical not to lose sight of the fact that an 
important part of this effort is to lay the groundwork for the future, which is to 
provide full electronic routing and authentication. This will require 
identifying security requirements, agreeing on priorities for re-engineering 
business processes, planning an adequate infrastructure (technology, 
procedures, and support), and developing a strategic and tactical plan for 
migrating to electronic documents. 

Summary 

U-M is working with forms owners and forms fillers to create a strategic and 
tactical plan for a gradual migration toward electronic documents. Concurrently, a 
number of pilot projects are being undertaken that will reveal the most cost- 
effective approaches and determine the necessary technical and support 
infrastructure that must be in place. The anticipated environment is one where 
computing is distributed and focused on the desktop. This environment is 
expected to offer significant benefits of economy and flexibility, but there will also 
be challenges. By making an investment in strategic and tactical planning, 
selecting small pilot projects that will have maximum payback, and involving our 
customers from the outset, we hope to ensure a smooth, gradual migration to a 
paperless workplace. The vision is clear; at U-M we believe it is critical to begin 
taking the steps toward achieving that vision. 
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Introduction 



The Comptroller's Accounting Office (CAO) at MIT developed the $SumMIT client 
server financial reporting application to provide multiplatform user friendly access to 
MITs financial database. $SumMITs current users include vice presidents and other 
senior officers, as well as department level users. CAO expects that $SumMIT will 
eventually replace CAO's popular mainframe financial reporting application, developed 
about five years ago, with a user friendly desktop integrated reporting and data input 
system. This paper describes some of $SumMIT , s current features and options. 



The purpose of $SumMIT is to provide user friendly access to MITs accounting 
data warehouse, which resides in a large relational SQL/DS database on an IBM 
mainframe. To accomplish this purpose, $SumMIT uses a client server architecture (the 
data tables reside on the mainframe, but the application runs on your workstation). 

$SumMIT is fully integrated with your workstation and takes advantage of its 
features, such as windows, your mouse, pull down and pop up menus, color monitors, and 
spreadsheets and word processors. Reports from $SumMIT can be printed locally or 
exported for use with other workstation software. 

The technical tools used to develop $SumMIT are briefly described below: 

• Omnis, the application environment. Because Omnis applications are 

workstation independent, $SumMIT can be executed on any platform supported by 
Omnis (currently including the Macintosh and Windows 3.x). 

Thus, a single set of development, documentation, and training has resulted in an 
application that runs on two platforms. 



Technical Background 
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Note: Omnis programs can simultaneously access data from databases of various 
types (although the $SumMIT application currently accesses only an SQL/DS 
database). 

DAL, a facility supporting client server architecture, DAL makes the connection b 
the mainframe and allows $SumMIT to query the SQL database and retrieve the 



TCP/IP networking. DAL utilizes the campus network, which is TCP/IP, 
allowing high speed mainframe/workstation interaction. 

Digital ISDN phones. DAL can also utilize MITs phone system to connect to the 
mainframe computer, but this method is considerably slower than networking. 

Other phone dialups. DAL can also utiltize a phone system external to MIT at 
varying modem speeds to connect to the mainframe, but this method is 
considerably slower than networking. 



1 ♦ Overview 

System purpose 

The $SumMIT application, developed in Omnis software, provides user friendly 
access to accounting data in a SQL/DS database on an IBM mainframe. All reports run on 
the subset of Institute accounting data to which the user has access. Some reports are 
especially for "power users" (users who can access all Institute data). 

Most options can be performed by clicking your mouse on buttons or selecting items 
from menus or lists. Reports can be "exported" to your desktop into spreadsheets or word 
processors or printed on your local printer. 



To access $SumMIT, once it's been installed, you double click on its icon. The 
logon screen displays, as shown below. 



results. 



$SumMTT application 



Logon 




Pleats enter your User ID and password.... 




USER ID [ 



password 



[Cance l] 




Connection Type 



MIT Network 
ISDN Phone 
Modem 19,200 
Modem 9600 
Modem 2400 
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After you oelec your Connectior Type, a/td enter your userid and password, the 
$SumMIT main mem. displays, as shown, belov/. 




$SumMIT currently includes four options — hierarchical, ad hoc, and special 
reports and the accounts menu. These options are described below, 

2, Hierarchical reports 

The $SumMIT hierarchical reports are preprogrammed reports that can be run on 
current or historical accounting data. 

The current year report* show expenditures (FYD) and budgets for the current and 
prior fiscal years, as well as percent growth of expenditures and budgets (for a sample 
report, see the next page). The historical reports show fiscal year expenditures for each 
year back to 1978 (none shown). 

When you select "current" or "historical" from the Hierarchical main menu, the 
screen shown below displays, 
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The reports display data by school, department, research sponsor, or account To 
select a report, click on its button. An example of the current school report is shown below. 



After running a school, department, or research sponsor report, you can break the 
data down further. For example, you can break down school data into data for its 
departments. An example of a department report is shown on the next page. 

Below is the school report run on current accounting data, You can display a report 
on the departments within a school, for example Architecture, by double clicking on the 
school's line. 



School Summary Report using Current Data 



School 


Su*<FYD'93> 


Sum<Bud*93> 


Su»<FVD '92> 


SumCBud '92) 


EXPE 
GROU 
* 


BUOO 
GROW 
* 


flrchl tecturt 


6,313,599 


30,547,798 


6,530,275 


27,086,770 


-31 


13* 


Eng i r*«r i rvg 


41,534, 154 


167,000,735 


42,095,942 


167,675,507 


-1* 




Human! tics 


6,218,276 


28,413,512 


6,465,654 


27,933,048 


-4* 


2* 


Management 


9,393,639 


36,036,396 


8,768,454 


40,383,366 


7* 


-11* 


Science 


38,690,326 


155,351, 191 


37,073,717 


151,281,561 


4* 


3* 


Other .Read. 


14,329,388 


187,067,314 


11,747, 192 


179,920,264 


22* 


4* 


Whi taker 


9,270,505 


11,379,814 


8,846,594 


11,932,201 


51 


-5* 


Inter apt .Lab 


24,405,795 


5,222,398 


24,851,431 


4,432,267 


-2* 


18* 


Library 


4,420,668 


14,264,725 


4,009,536 


13,612,524 


101 


5* 


Non . Rcactem i c 


87,298,754 


451,473,419 


1 12,'J10,OS9 


428,917,906 


-22* 


5* 


Total 


241,875, 104 


1,086,757,302 


262,898,853 1, 


053, 175,414 


-8* 


3* 



Double Click on Entry to see Departmental Breakdown 



(Hierarchical "Current" Menu] [ Hierarchical Main Menu 



The department report for the schocl of Architecture is shown below. 



Department Summary Report 



Department Summary Report for Architecture 

Department Sum<FVD'93) Su»<Bud'93> Su»<FVD *92> Sum<Bud *92> 


EXPE 
GROU 
* 


BUOG 
GROU 
* 


Rrch.Hdq 


257,467 


1,531,321 


428,225 


1,414,822 


-40)1 


8* 


Rrch.Dpt.Hds 


67,708 


270,833 


9 1 , 920 


315,753 


-26* 


-14* 


Rr ch. Special 


54,907 




133,769 




-59* 




Rrchi tecture 


786,076 


5,313,894 


1, 170, 159 


5,073,851 


-33* 


5* 


flga . Khan . Prg 


146,875 


1,635,550 


312,019 


1,028,737 


-53* 


59* 


Rtal .Esi.Dcv 


329,503 


2,358, 135 


314,496 


1,919,460 


5* 


23* 


Urban Studle 


1,011,675 


4,425,836 


1,008,400 


4,302,047 




3* 


Mtdia.Rrls.S 


252,322 


1,683,849 


301,675 


1,479,657 


-16* 


14* 


LRP 






-6,293 




-100* 




CRUS 


35,986 


104,710 


21,563 


239,617 


67* 


-56* 


H«d i a. Lab 


3,369,080 


13,223,670 


2,754,331 


11,312,826 


22* 


17* 


Total 


6,313,599 


30,547,798 


6,530,275 


27,086,770 


-3* 


13* 



Double Click on Entry to Jee Account Type Breakdown 



Hierarchical Main 



Menu ] 
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3. Ad hoc reports 



You can run M ad hoc" (or user-defined) reports on current or historical accounting 
data. Reports run on current data compare expenses and budgets for the selected expense 
types for the current and prior fiscal years. The historical reports compare expenses for 
expense types over the last fourteen years. You select the expense types (or "object codes", as 
they are called at MIT) to compare for the chosen rows and columns. 

When you select M Ad hoc" from the main menu, a screen for selecting current or 
historical data displays (not shown). 

Current reports 

If you select "current", the screen shown below displays. 



Define Report 



Ual id Col 



Choose your report vie* by se lect i ng Report By/For. 
Then double cl Ick on desired columns, rows t expense types. 

Chosen Columns: 



'93 FVD Expenses 
'93 FVD Budget 
'92 FVD Expenses 
'92 FVD Budget 
* Expense Growth froe '92 to 'QC 
II Budget Oroeth froe '92 to '93 
% of Budget Expended In '02 
X of Budget Expended In 'g3 



Choose 



Remoue 



Ual id Rows: 



SuMorize Rll Schools 
School of Architecture 
School of Engineering 
School of Hueonities 
School of Management 
School of Science 
Other Academic 
Non-flcademic 



[ Choose") 
( Remoue ] 



Chosen Rows; 



Clear ] 



Ual I d Expense Types 



207 Tenured Faculty 
210 Hon tenured Faculty 
214 Other Academic /flam in 
220 Summer Facu I ty 
230 Research Staff 
250 Service Staff 
320 Support Staff 
350 Students 



[ Choose^) 



Chosen Expense Types 



[ Remoue) 



Clear ) 



O 



<>1 



| Reporting Timm ▼! 
Current 



j Report By 
School 



Command/double click valid Expense Type to see detail Expense Codes 



1 Report For ▼! 
Ri I Recounts 



[Create Report 



Rd Hoc Menu] 



Your choice of "current" or "historical" determines valid report columns, as shown 
in the top leftmost screen box. (To cycle between "current" and "historical", you can use the 
Reporting Time pull down menu at the top right.) 

To display valid report rows, as shown in the middle leflhand box, you select a 
"Report By" option (see below). The default option is by "School". 



Repor t By 



✓ School 
Deportment 
Sub Deport 
Group 

Supervisor ► 
Recount 



ERLC 
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The default "Report For* option is "All Accounts", resulting in four reports, one 
each for general, fund, research, and all accounts. Other options are to display only the 
"General", "Fund", or "Research" report. 

To create a report, you need to select columns, rows, and expense types to compare. 
To select a column, row, or expense type, you highlight its line in the lefthand box and click 
on "Choose" to copy it to the right hand box. 

The sample screen below defines a report on current and prior year expenses and 
budgets in the School of Engineering for expense types 207 and 210 (faculty salaries tenured 
and non-tenured). 



Define Report 



Ual Id Colunn*: 



Choos* your report uIm by selecting Report By/For. 
Then double ciick on desired columns, rows & expense types. 

Chosen Coluens: 



'03 FVO Exp •tim* 
'93 FVO Budget 
'92 FVO Expanses 
'92 FVO Budget 

ft Exports* Growth fro* '92 to 
ft Budget Growth frow '92 to ' 
ft of Budgot Expended in '92 
ft of Budgot Expended in '93 



Ual Id Rows: 



Suwkorizo All Schools 
School of Architecture 
School of Engineering 
School of Humanities 
School of Management 
School of Science 
Other Bcadeelc 
Non-flcadee I c 



Ual Id Expense Types 



20? Tenured Faculty 
.?. Jfef^flMT o ,<J, , Focu j t y 



220 Suweer Focu 1 ty 
230 Research Stoff 
250 Service Staff 
320 Support Staff 
350 Students 



Choose 



Choose 



Remoue 



Clear 



Choose 



Remoue ) 



Clear j 



'92 FVD Expanses 
'92 FVD Budget 
'93 FVO Expenses 
'93 FVD Budget 



Chosen Rows: 



School of Engineering 



Chosen Expense Types 



Remoue ] 



Clear ] 



207 Tenured Faculty 
210 Hon tenured Faculty 



Reporting Time ^| 
Current 



| Report By ^| 
School 



1 Report For ^| 
Rl i Recounts 



[Create Report) 
[Rd Hoc Main] 



Coeaond /double click Ual id Expense Type to see detail Expense Codes 



A sample report for All Accounts is shown below. 



School 



FVD 92 



Bud 92 



FVD 93 



Bud 93 



Eng i neer I rvg 
Ten.Fac 
Nonten. Fac 

Total 



2,271,869 
451, 146 



20,423,919 
3,813,245 



I, 162,468 
397, 184 



20,443, 160 
3,941,221 



2,723,016 24,237,164 2,559,652 24,386,381 



Rd Hoc Define ) 



ffld Hoc Main) 



[rearrange columns) 



[<■][*>] [J* fault coiuu^r] 



o 

ERIC 
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Historical reports 

If you select "historical" from the ad hoc Reporting Time menu, the screen shown 
below displays (except that no columns, rows, or expense types are selected). The columns 
available (top lefthand box) include year end data for 1978-1992. 

The sample screen below defines a report on year end data for 1973, 1982, 1988, and 
1992 from the School of Engineering for expense types 207 and 210. 



Define Report 



Ual id Col 



Choose your report vlee by selecting Report By/For. 
Then ooctole click on desired coluens, rows t expense types. 

Chosen Co I inns: 



FY7* , 


& 

B 

w. 

m 
i\i 

m 
<X 


Choose ] 


FV79 
FV80 

Fvei 

FV82 
FV83 
FV84 
FV85 




[ Remoue j 


[ Clear J 




Ualld Rows: 




Sueeorlzo Rll Schools 
School of Architecture 
School of Engineering 
School of Humanities 
School of Honqgeeent 
School of Science 
Other Bcadeelc 
Non-ftcadee 1 c 


<> 
<> 


Choose ] 




[ Remoue ] 
[ Clear ] 




Valid Expense Types 




145 Funds ftval table 
igg Incoee 
207 Tenured Faculty 
210 Nontenured Faculty 
214 Other Acadee i c/Ade 1 n 
220 Sueeer Faculty 
230 Research Staff 
250 Service Staff 


St 

8 


[ Choose 


Si 

w 


Remoue ] 




[ Clear ] 





FV7S 
FV82 
FVSi 
FV02 



Chosen Rows: 



School of Engineering 



Chosen Expense Tgpes 



207 Tenured Focu I ty 
210 Nontenured Faculty 



| Reporting Tlee 
History 



Report By ^| 
School 



C on e nd /doub I e click Ualld Expense Type to see detail Expense Codes 



f Report For ^| 
fill Recounts 



[Creote Report] 
— | (fld Hoc Main] 



To run the report, click on "Create Report". A sample report for All Accounts is 
shown below. 



Rd Hoc Report for Rll Recounts 



School 



'FV7B* 



*FV82* 



•FV88* 



, Fvg2* 



Engineering 
Ten.Fac 
Nonten.Fac 

Tot Engineering 

Total 



5,081,331 
1,680,462 
6,768,853 

6,768,853 



7,783,013 
2,941,718 
10,730,731 

10,730,731 



14, 123,071 
3,362,762 
17,487,840 



17,338,964 
3,689, 122 
21,228,086 



17,487,840 21,228,086 



[reorrange coluens") 



[<-] [->] (default coluens) 



[ fld Hoc Def ln« ] 



(Rd Hoc Main] 

® 



o 

ERIC 
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4. Special reports 



This section describes the reports on the Special Reports menu, showr* below, which 
is for power users only. 



'Special Reports 



Underrecouery 
Fund Recount MTDC 



Underrecovery reports 

The term "underrecovery" applies to accounts on which MIT "underrecovers" 
operating expenses (that is, the overhead rates are lower than the standard rate). The 
underrecovery report gives MITs high level financial officers a means of projecting and 
tracking underrecovery. 

When you select "Underrecovery* from the Special Reports menu, the menu shown 
below displays. 



I 



Underrecouery of OH Menu 



1 




School 




Department 




Research 
Sponsors 




Account 




Underrec Type 


Main Menu 





You can run underrecovery reports by school, department, research sponsor, 
account, and underrecovery type. The department report is shown below. 

Deportment Summary Heport lor Hi.1 ueporiments 



DttportMnt 



Bud'93 



FVO 12/92 



Urban SludU 
Rtro.ftstro 

Civl I.Eng 

rtat.Scl.Eng 

Ocwn.Eng 

LCS 

BioUch.Ctr 
LEES 
CTPID 
UT 

Economics 

PSTS 
CIS 

SStl.tosftarch 

Biology 
Chemistry 

EflPS 

Canc«r .Ctr 
LNS 

l*i i iakw* . Co I 

HST 



9,»36 



10,437 



•,767 



12,530 
7S3 
11,941 
-422 
§.660 
-181 

6,317 
-16 
S3, 437 
11,643 
43,456 

4,909 
19,5*9 
11,711 
119,030 
71,143 
20, W4 

6,393 
20,668 
•3,923 
•21 

7,634 



o 



S 



Double Click on Entry to ut Account Brt.kdovn 



9 
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The Bud column displays underrecovery budget dollars; the FYD column displays 
actual underrecovery dollars (object code 961). 



You can further analyze the data by double clicking on a row, for example 
SSM.Research. The sample report below displays the underrecovery data for 
SSM.Research by account number. 

To display the underrecovery budget record for an account, click on the account 
line to highlight it. For example, the underrecovery budget record for account 76354 
displays at the bottom of the sample screen. 



Recount Breakdown for ssM.rteseercn 



ftcct • D«parU«nt 



Sponsor 



Bud '93 



FVO 12/92 



75362 
75393 

□fig 



SSfl . R«s«orch 
SSM . Reseorch 



Nonprof I ts 
Nonprofits 

T$r^ — 



32BE 



Total 



8,7C7 



113,3C3 
711 

zee 

119,030 



Fisoal Yoar 



1993 




Litstor 


NSF .WOMEN 





Man*9*mtnt 



(* » no und*rrtoov*ry budget) Double Click on Entry to see Account Information 

School 
Sponsor Grp 
Sponsor 



Proposal ID 



NSF 



NSF 



Remarks 



<> 
<> 



You can double click on an account's line to display chart of accounts data for the 
account (not shown). 



Fund account MTDC reports 

This report shows the difference between two methods of calculating overhead on 
fund accounts (that is, MIT accounts drawing on gifts received for specific purposes). 



When you select "Fund Account MTDC from the Special Reports menu, the menu 
shown below displays. 




| By School 




| By Department 




| By Sponsor 


i 


j By Label 






i 


Main Menu 



You can run fund account MTDC reports by school, department, research sponsor, 
and label. For example, the label report is shown below. 



■31 



Lnbel Summary Report for fill Labels 



Label 



Impact 



TDC 



f— IDC - Salary Base ~] | IDC - MTDC - 

Bl 1 1 Rate Actual Bi II Rate 



Actual 



Professorship 
Career Development 
MIT Revenue Sharing 
flthena 

CAES 
flga Khan 

No Sponsor-Zero IDC 
NSF Pres. Voting Inves 
Other Fed-Fixed IDC 
Draper /Uhi tehead Fel 
Non-Fed Fixed IDC 
Fel low /scholarships 
Sloan Bas /So I or Enrg 
Co II eg I u* 
Research 
Education 
Department a I 

Total: 



-72,525 

782,370 
428,651 
2, 166, 181 
1, 114,253 
460,416 
2,031,845 



9,657,567 
2,002,496 
1,569,276 
109,094 
3,719,855 
609,797 
5,761,950 
1,845,621 
333,259 
2,043, 106 
3,042,768 

13,095,483 
1,371,798 
9,373,792 
3,711,981 
1,446,690 

15,367,350 



5,022,315 
836,460 
385,525 
3,397 
799,827 
226, 184 
1,971,800 
844,491 
162,886 
290,658 
993,343 
50,723 
73,478 
666,915 
308,570 
159,810 
714,635 



246,245 
31,396 
290,658 
81,761 
49,914 
73,478 
664,807 
302, 169 
159,810 
726,591 



4,613,381 
856,081 
751,391 
10,404 

1,697,369 
264,451 

2,443, 121 
855,228 
126,781 
218, 134 

1, 147,800 
832,284 
502, 129 

2,830,988 

1,416,421 
629,226 

2,758,435 



246,245 
31,396 

218, 134 
81,761 

832,284 

502, 129 
2,830,988 
1,416,421 

629,226 
2,758,435 



6,920,191 75,062,784 13,511,016 2,626,827 21,953,624 9,547,018 



Double Click on Entry to see Account Breakdown 



You can further analyze report data by double clicking on a row, for example 
Research. 



9 
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5. Accounts menu 



When you select "Accounts" from the main menu, *he Accounts menu displays, as 
shown below. This section describes some of the options on the Accounts menu. 




Uieui 
Recount List 


Object 
Description 


Chart 
Information 


View 
Rate Tabie 


Recount 
Summary 


Define Rcct 
6roups 


Power 
User 




Consolidated 
VTO 


Consolidated 
VTD ♦ Forecast 




Main Menu 



View Account List 

From the top window, click on "View Account List" to list the five-digit account 
numbers accessible to your userid. (At MIT "account numbers" represent sources of 
authorized income to which expenditures can be charged.) A sample screen is shown 
below. 



Recount List 



3 



Rll Ruthorized Recounts 



12671 CELL SORTER LABORATORY 

12707 CANCER CTR - CHEMISTRY LAB - PEP 

12741 CANCER CTR - CHErtSTRV LAB - DMA 

13286 CENTER FOR CANCER RESEARCH-DSR S 

14436 CCR-OENERAL 

15037 BIOLOOV - CCR SUPPORT 

15608 CANCER CENTER - STRRTUP FUNDING 

15929 CTR FOB CANCER RESEARCH-N/R EQUI 

20148 PROCTER AND 0AM8LE COMPANY 

20362 CHARLES S. KRAKAUER FUND 

22205 HEREDI TRRV DISEASE FOUNDATION 



Double-Click for Account Summary 



1 72 
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Options available by account 

The table below describes options available for an account or account group. Users 
can create account groups using the "Define Acct Group" option on the Accounts menu. 



For... 


you can M « 


a single account 


• display chart information (see below). 

• display an account summary report (see 
below). 


a single account or 
an account group 


• run YTD reports (see next page), 

including actuals by expense type for the 
current month or all months in the fiscal 
year to date. 



Chart information 

A sample screen of "chart information" for an account is shown below. 



Chart Information for Recount 15nnn 



Account Name 



BIOLOGY - CCR SUPPORT 



Supervisor 



Addressee 



Eftotiv* D*tt 
Account Purpost 



8110O1 



Expiration D*t* O000O0 



Dtptrtmtnt Number 



151000 





SMITH, JANE 


Name 


DOE, JOHN 




56-519 




Address 


E17-112 





Account summary report 

An example of the account summary report is shown below. The columns are: 
current month expenditures (Current), FYTD expenditures, cumulative expenditures (for 
accounts with life spans of more than one year), and budget dollars. 



Account Summary for Account 15nnn 



Figures toed on 1 0/92 Summery Data 





Current 


FVTD 


Cumulative 


Budget 




Total Funds: 
To ta 1 I nco»e : 
Total Expenditures: 
Exp. Net of Income: 
Unexpended Balance: 


0 
0 

37,532 
37,332 
0 


0 
0 

53,395 
93,395 
0 


0 
0 

93,393 
93,395 
508,072 


0 
0 

601,467 
601,467 
0 


O 

o 



This Month VTD 



Complete VTD ] 



0 Forecast future spending 

□ Use Chart Overrides 

□ Use Proposals 

Use Purchase Orders 

□ Use OC Overrides 



Accounts Menu 




_ ion — i < 3 



From the account summary report, you can run the account's YTD report. This 
report displays expenses by expense type; it can include a forecast of future spending for the 
months remaining in the fiscal year (based on algorithms outside the scope of this paper). 

The "this month YTD" report includes current month actuals only. The "complete 
YTD" report includes monthly actuals for each month in the fiscal year to date. 

YTD reports 

A example of the YTD report is shown below. You can run a YTD report on a single 
account or an account group. 

The report columns are fiscal year to date expenditures (F Y Date ), projected 
expenditures for the months remaining to the end of the fiscal year (Projected), the sum of 
these two columns (F Y Total), and the account's fiscal year budget (Budget). By 
comparing the F Y Total and Budget columns, you can determine if the account is projected 
to be overrun (that is, if expenses are projected to exceed available funding). 



Double-Click on a line tc jiaplty Dehil 


VTD for Recount 15nnn ■ 

Information... 










1 Description 


Cdm 


F V DaU 


Projected F 


V Total 


Budget 




FftCULTV SftLfiR 1 ES-TENURE-ON 
FflCULTV SftLfiR IES-NO TENURE-ON 
OTHER ACADEMIC STRFF-ON 
RESEARCH STfiFF-ON 
SUPPORT STAFF - ON 
E.B. BILLING RATE 
OFFICE SUPPLIES 
PUBLICATIONS 
CONFERENCE EXPENSES 
POSTAGE HAILING t SHIPPING 

TnT rvo 


207 
210 
214 
230 
320 
401 
468 
484 
591 
812 
r\-tA 


10,556 
7,858 
18, 155 
4,292 
10,374 
22,227 
164 
0 
0 
201 
no ™«: 


57,331 
27,502 
13,933 
17,210 
0 

42,795 
0 
230 
975 
0 

icn n-r> 


76,887 
35,360 
32,088 
21,502 
10,374 
65,022 
164 
230 
975 
201 

IT* 


157,445 
149,916 
0 
0 

25, 139 
122,693 
0 
0 
0 
0 


<> 

5 

i 

o 


Zero uolues are displayed for all month columns except the current month. 




[rearrange columns] 


^<»j ^■>j [default columns] 






outstanding POs [graph] 


Print VTD Report J 




Recounts Menu 

- 


) 



You can select report options, as needed, including: 

• display additional report rows and columns (to display additional columns you 
click on the right and left arrows above the "Print YTD Report* button), 

• rearrange report columns (by clicking on the "rearrange columns* button and 
selecting the columns to be displayed in the order of display from a list), 

• display detail by expense type by double clicking on a line (for a sample report, 
see the next page), 

• within salary expense type, display complete salary distribution for a person, 

• display outstanding PO's, 

• graph report data for salary or other expense types (see next page for more). 

174 
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0 
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Below is a sample detail screen for expense type 230 (Research Staff - On Campus). 
IP = = ! == 3 : Sandj | n f orma tion for Object 250, Recount 15nnn 



RESEARCH STAFF-ON 



Ham* 


SSN 


DPT0UN 


DPTEE 


PCT 


BDflTE 


EDflTE 




DOE, JOHN 


287468669 


151000 


159700 


100.00 


9209 15 


930630 


<> 


SMITH, JANE 


044502779 


151000 


159700 


10.00 


920701 


930630 




WILSON, GENE 


560709723 


151000 


159700 


100.00 


920101 


920130 






3 












o 



DoubW-olkk on * p+rson to rtvWv tholr allocation across Accounts 



graph people by account Accounts Menu ) 



Grapliing options 

Within YTD reports, you can graph data by expense type, as described below. 



For... 


you can graph— 


salary expense types 


• for an account, percent salary distribution by 
person. 

• for a person, percent salary distribution by 
account. 


other expense types 


• single expense type by month. 

• FY Date, Projected, FY Total, and Budget 
columns for two expense types. 

• YTD spending for all expense types. 



Below is a graph projecting research staff salary distribution to an account (in 
percent) for the fiscal year. In $SumMIT the graph uses three colors, one for each person. 
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Introduction 

The University of Michigan is one of the premier research universities in 
the world. More than 50,000 students are enrolled at the University's three 
campuses located in Ann Arbor, Flint and Dearborn. A total of $346,000,000 
was spent on research activities during fiscal year 1991-92. Total revenues 
from all operations of the University totalled more than $2 billion during fiscal 
year 1991-92. 

The Financial Operations Office is the central accounting office for the 
University. Approximately 160 employees work in the various fund areas and 
service organizations within Financial Operations. The Accounts Payable and 
Travel Audit Office processes approximately 90 percent of all non-payroll 
disbursement transactions for the University. This office processed over 
750,000 transactions during fiscal year 1991-92. Many of these transactions 
were vendor invoices for products/services rendered through the University's 
Purchasing Department. When a University department needs a particular item 
that is not available from our Stores operation (a large warehouse that stocks 
many of the basic items needed on a day-to-day basis), they are to complete a 
Purchasing Requisition. A purchase order number is then assigned and the 
order is sent to the vendor. The products/services are provided and the vendor 
submits an invoice to the University's Accounts Payable and Travel Audit 
Office, noting the purchase order number on the invoice. The invoice is then 
audited by our office by comparing the items on the invoice with what was 
actually ordered on the purchase order. If everything matches, a paydate is 
assigned to that invoice and recorded on the database. 

The database management systems that are used at the administrative 
data center are IMS (Information Management System), DB2 and Oracle. IMS 
is the main on-line and batch database processing operating system that supports 
all the application systems for the major administrative departments 



(i.e. Financial Operations, Payroll, Purchasing, Personnel, Registrar, 
Admissions, Student Accounts, etc.). The administrative data processing 
system supports a large 3270 network for both on-line and remote dialup. 
Users (University departments) can access administrative systems, E-mail, and 
the gateway to Internet. The system is accessible by employees of all three 
campuses. 

The current Purchasing/ Accounts Payable database was created in 1978. 
The purchase order and purchase order invoice detail screens are widely used 
throughout the University. Approximately 1 10,000 purchase orders are created 
annually, which generates in excess of 375,000 vendor invoices. 

Accounts Payable and Travel Audit Office 

The Accounts Payable and Travel Audit Office perform the following 
functions for the University; 

Audits vendor invoices against the purchase order and approves the invoices 
for payment. 

Audits and approve for payment non-purchase order transactions (travel 
expense reports, Federal Express airbills, imprest reimbursements, etc.). 
Telephone customer service support for University departments and vendors. 
Imprest cash fund approval and reimbursement processing. 
Credit memo processing. 

As the University grew in size and the volume of transactions increased 
in number during the 1980' s, central administrative financial support suffered. 
The necessary staffing and systems enhancements were delayed time and time 
again. By the late 1980' s, the Accounts Payable and Travel Audit Office had a 
horrible reputation throughout the University community and with the 
University's vendors for extremely slow payment and inadequate customer 
service support. In 1989, it was recognized that the University's overall image 
was being affected by this adverse situation. The beginnings of a "Quality" 
movement were spreading through certain areas of the University and it was 
decided to make every reasonable effort to improve the image and quality of 
work performed by the Accounts Payable and Travel Audit Office. There were 
two underlying reasons for doing this: 

1. The Accounts Payable and Travel Audit Office was one of the primary 
contacts with the outside community. 

2. The poor quality of the Accounts Payable and Travel Audit Office adversely 
affected many other areas within Financial Operations. 
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During the 1980's, one person was assigned the responsibility of 
answering the telephones. This person was equipped with a two-line telephone 
instrument, a headset and a computer terminal to access the 
Purchasing/ Accounts Payable database. If you have ever worked in a position 
where the telephone completely dominated your every move, then you may 
realize just how difficult this task was. Statistics are not available on how many 
calls this person handled per day, or how many calls could not get through 
because the line was busy. Assuming the average call is 2 minutes, the 
maximum number of calls this person could handle per day is approximately 
200. Our Voice Response Unit currently receives 350-400 calls per day. 
Applying the same rates of volume increases to the number of calls as we know 
exists with the number of invoices processed, this tells us that in any given day, 
approximately 100-125 callers could not get through due to the line being busy. 
Many of the complaints registered against our office during the late 1980's were 
that of the difficulties of getting through on the telephone. 

In 1989, we decided to increase the number of staff that were trained to 
answer the telephone from one person to four. A telephone group was 
established through our Telecommunications Office that would uniformly 
distribute calls to those in the group. Two representatives were in the telephone 
group at any given time. We thought this would provide more than enough 
service. We were wrong! The telephones continued to ring constantly and it 
was obvious that something else was needed. Many of the calls were very 
routine, for example; "Can you tell me if this invoice has been paid?" This 
required the representatives to do an IMS transaction and relay the information 
on the screen to the caller. This would prevent these employees from 
performing other necessary tasks. 

We had a decision to make. Should we: 

1. Increase staff to a level that can adequately process all of the requests 
received from the University departments and vendors? 

2. Look into other technologies, specifically voice response units? 

3. Investigate procedure and policy changes that may relieve the workload of 
our current staff to a more acceptable level? 

We decided to immediately implement some procedural and policy 
changes, and begin looking into the possibility of obtaining a voice response 
unit. A few vendors were asked to do presentations and the decision was 
eventually made to purchase a voice response unit. 
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The Voice System 

The Voice Response Unit consists of four main functions: 

1 . Telephone operations. 

2. Application development and processing. 

3. Screen identification. 

4. Speech recording and usage. 

The telephone operation covers many features that are performed in 
familiar telephone systems. The voice response unit can answer the telephone, 
transfer calls to both internal and external numbers, perform conference calls, 
put callers on hold and initiate calls. Telephone processing includes checking 
for several actions and inactions. These include monitoring the amount of time 
a caller is on the line without entering data, the amount of time it takes to get a 
dial tone, detecting a busy signal and incomplete call transfer or initiation. 

Application development and processing include the preparation and 
coding of the actual script that will be used and its execution. It is the 
application that makes it possible for the unit to detect a specific screen and to 
act upon the data displayed. This includes the processing of a telephone call in 
the same sequence in which a person would handle the call. A simplified 
example is; answer the telephone, present the caller with the necessary options, 
process the request, communicate the requested information to the caller and 
gracefully terminate the telephone call or transfer the caller to another service 
representative. 

Screen identification includes identifying those specific screens, such as 
an EMS screen from a mainframe, a microcomputer spreadsheet screen or a 
screen from a microcomputer database program. This also includes detecting 
blank, incomplete or unrecognized screens and processing the exceptions in a 
manner that does not cause the application to end unexpectedly. The voice 
response unit system provides a mechanism to specifically identify sections of 
the screen that the unit needs in order to process calls efficiently. 

One important part of the application is the speech. Each response to the 
caller is a spoken word or phrase. Responses are coded as text in the 
application, then the text is associated with an audio recording and stored on 
disk as digital representation of the spoken voice. Storage of recorded voice 
requires a large amount of disk space, thus it is very important that phrases be 
kept as simple and short as possible. Short and concise responses will also 
make the system easier to use for the customer. 
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Considerations in System Design 



Once other departments learned that we were going to purchase a voice 
response unit, some inquired about possible applications within their units. The 
University's Payroll Office and Staff Benefits Office both requested to be 
included in this venture. The Student Accounts Office (also part of Financial 
Operations) would also be included, in addition to the Accounts Payable and 
Travel Audit Office. 

To provide the most efficient service to the targeted users, we 
implemented the voice response unit in a modular fashion, as recommended by 
the vendor. Three modules were purchased: one for the Accounts 
Payable/Travel Audit, Student Accounts and Payroll applications, one for the 
Staff Benefits application and the remaining module would be used for 
application development and maintenance. 

When designing an application for a voice system, one should follow the 
standard system design rules and principles; such as develop modular code, 
develop reusable routines, build transaction tables, keep algorithms and Boolean 
logic simple. In addition, you need to be knowledgeable of the telephone 
system in use; the options available (call waiting, conference calling, etc..) and 
the screens that the voice system will access to retrieve the data. It is necessary 
to work closely with the telecommunications department and the data processing 
department when setting up your voice response unit. 

The telecommunications department's involvement is to install the 
connections between the voice response unit, the telephone system and the 
computer system where the data originates. This could take months to 
complete. Data lines and voice lines will need to be installed. The 
administrator may need two voice lines; one for the administrator of the unit 
and another for the vendor to use to access your voice system for debugging 
purposes. The vendor we selected markets a dial-in package that proved very 
useful when there were problems with the system. They are able to access our 
application from their home office. 

Data processing people are involved from the perspective that they 
manage the host computer that holds the data to be accessed by the voice 
response system. You probably won't be able to simply plug in the voice 
response unit, write an application, redirect your telephone and then sit back 
and watch the lights blink! The administrator will need to work with system 
security personnel to define new terminals and user ID's. The internal audit 
department may also need to be consulted. The EDP auditors on our campus 
were very concerned with the security issue. Since the transactions used were 
only inquiry transactions, we were able to get over this hurdle; however, if we 
had planned to update the IMS database through the voice response unit, this 
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would have been a much more difficult obstacle to overcome. In some cases, 
you may want a new' screen designed or other mainframe programs enhanced. 
This may be necessary if you are searching through multiple screens for a few 
data elements. Very little of this can be completed prior to developing the voice 
script. While developing this script, it may become apparent that a modified 
screen will be required to decrease the desired response time. It will become 
even more important to have the data processing department involved as early in 
the application design as possible if you plan on updating or storing data on the 
mainframe. 



3270 Emulation 

Utilizing the IBM standard 3270 data transfer mode, the voice response 
unit appears as a dumb terminal on the mainframe network. Through the 
system utilization process, as with a terminal operator utilizing a terminal, the 
voice response unit sends the necessary transactions and passwords to the 
mainframe enabling it to sign on and access data. Once the voice response unit 
has successfully signed on, the system awaits an incoming call. Upon receipt of 
a call, it goes into the routine described below. 

The Accounts Payable and Travel Audit Application 

All of our customers' calls are processed through the voice response 
unit. By calling our main Accounts Payable and Travel Audit number, 
(313)764-8212, the caller is asked to press 1 if they have a touch-tone 
telephone. The next layer of the script contains the main menu. The various 
selections are: 

For purchase order information, press one. 

For Federal Express information, press two. 

For other freight information, press three. 

For Travel/Host Expense information, press five. 

For credit memo information, if your vendor name begins with the letter 
A-K, press six. 

For credit memo information, if your vendor name begins with the letter 
L-Z, press seven. 

To speak to a customer service representative, press zero. 
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Most of the callers will press one for purchase order information. All of 
the other selections use the voice response unit to direct calls to the appropriate 
section of the office. The purchase order information selection will lead the 
caller through layers of script to Sbtain payment information. 

University of Michigan purchase order numbers begin with a letter and 
are then followed by five numbers (F38452). One of the IMS transactions that 
is utilized extensively by our office is the purchase order invoice information 
transaction. The user would signon to IMS, go through the necessary security 
process and type in the following: 

POINV F38452 

After pressing the ENTER key, the following screen would appear: 



PO# F38452-00000 DATE 05/07/92 
POSTAT 0 FOB CD (NET/30) 
POTOT 9000.00 INVTOT 14.04 

ACCT 238751 2452 CM TOT 0.00 
AUTH SIGNOR J RODGERS 
REQCDS BS BL NB 

FOLLOWUP 06/18/92 NOTICE DTE 
CONTRACT PERIOD 07/01/92-06/30/94 
PO SUPERCEDES PO# CE61170 



POITM 
IVIIM 



VENDORS 13754N 

FAIR LANE FORD SALES, INC 

145 85 MICHIGAN AVE 

DEARBORN MI 48126 



NOTICE NO 000 AMENDS 001 BUYER JBS 



AMEMO 01 


RECEIVED CM 6891 TO 


CANCEL INV 


6289. TLB 9- 


-9-92 




INVOICE 


NUMBER DATE ST 


INVOICETOT 


NET AMOUNT 


PAYDATE 


APRDATE BATCHSEQ 


UN5210 


09/24/92 DN 


42 .94 


42.94 






12227 


10/05/92 N 


14.04 


14.04 


11/06/92 


J5G00-14 






CHECK# 917201 11/06/92 CP# 


382048 RL# 00000 


13189 


10/12/92 WN 


81.28 


81.28 




F1J00-49 


14353 


10/20/92 WN 


47.85 


47.85 




F1J00-48 


6289 


08/14/92 WN 


25.50 


25.50 




F1J00-45 


6937 


08/27/92 WN 


25.50 


25.50 




F1J00-44 


97839 


07/06/92 WN 


12.16 


12.16 




F1J00-47 


98848 


07/13/92 WN 


32 .89 


32.89 
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**** CONTINUE **** 



Alt-Z FOR HELP 0 VT102 



FDX 



9600 E71 ° LOG CLOSED ° PRINT OFF ° ON-LINE 
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This screen has always been widely used by our service representatives 
to answer inquiries from University departments and vendors. This screen 
includes the vendor name and address, payment terms, invoice number, invoice 
date, purchase order status, invoice total, net amount to be paid, the check 
number and checkdate if already paid and other necessary information. 
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If a previously working voice response unit application suddenly begins 
relaying scrambled information, then someone has probably changed the format 
on one of the screens your application is accessing. It is CRITICAL that there 
is a procedure in place that will enable you to be notified whenever a screen 
used in the application is going to be modified! Learning of a modification 
AFTER it occurs WILL CAUSE MAJOR PROBLEMS. You also will need to 
be notified if another screen is being added or a screen is being removed from 
the mainframe application. We created a separate transaction that was a mirror 
image of the POINV screen, with explicit instructions not to modify this 
transaction without our approval. 

Our callers are asked to enter the initial letter of the puxhase order 
number. In this example, the caller would press the #3. The #3 on a telephone 
contains the letters D, E and F. We had to include another layer in the script to 
get around this situation. The caller is instructed that if the purchase order 
number begins with a D, to press one; an E, to press two; an F, to press three. 
This will inform the voice response unit of the first character of the purchase 
order number. The caller is then prompted to enter the remaining numbers of 
the purchase order; in our example we would press the 38452 keys on the 
telephone. In order to reduce the amount of information relayed to the caller 
for lengthy purchase orders, the caller is asked to provide the invoice date of the 
invoice in question. We considered using the invoice number, but many invoice 
numbers contain dashes, asterisks, letters, etc. This would have required that 
additional layers be installed to identify the specific invoice in question. 
Therefore, we decided to use the invoice date. Callers are instructed to enter 
the date in the following format: 



MMDDYY 



This supplies the necessary information to the voice response unit to deliver 
only the desired information. 

In our example, once the purchase order number F38452 has been 
entered and the invoice date of October 5, 1992 (this would have been entered 
100592) has been supplied, the voice response unit will read the IMS screen and 
integrate the information on this specific screen with standard speech 
instructions as follows: 

Standard S peech Specific Screen Information 



Invoice Number 
Dated 

In The Amount Of 
was paid on 
check number 




12227 

October 5th, 1992 
Fourteen dollars and 4 cents 
November 6th, 1992 
917201 
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If an invoice has been assigned a paydate, but a check has not been 
prepared, the voice response unit will respond with "the invoice is scheduled for 

payment on In our example, many of the invoices have a "W" in the 

status field. This means that the invoice has been received but has not been 
processed for payment. The voice response unit will relay the information that 
the invoice is "in process." At the end of each request, we ask the calle. if they 
want the information repeated, or if they want information on another purchase 
order, or if they wish to speak to a service representative. Depending on their 
selection, the caller will be returned to the appropriate section of the 
application. While the voice response unit is waiting for the IMS screens, 
phrases like "One Moment Please" or "Please Hold While We Search Our 
Database" should be utilized. Otherwise, the caller will be hearing nothing but 
silence on the line and may think that the unit is not working. 

Many of the questions which callers have cannot be answered by the 
voice response unit. The callers are given the option of talking to a service 
representative many times throughout the Accounts Payable script, by pressing 
the "0" anytime from within the application. The voice response unit will 
automatically transfer the caller to a service representative if the invoice in 
question has a status of "F" in the status field. This means that an invoice did 
not pass audit, and there is a problem that needs to be corrected before a 
paydate can be assigned. There is no further information that the voice 
response unit can provide on these invoices, therefore, the caller is 
automatically transferred to a service representative. 

Developing the Applications 

As mentioned previously, one module contained the applications for 
Accounts Payable and Travel Audit, Student Accounts and Payroll. The term 
"applications" may not be the most accurate. Actually, they were sections of 
the script within one large application. This had its advantages: utilizing 
standard routines such as checking for non-touchtone telephones; error situation 
messages; call transfer procedures and screen paging. 

If it becomes necessary, however, to create unique messages where a 
standard message was used, the advantages of standardization have suddenly 
turned on you. Not only do you need to determine how to create the 
uniqueness, you need to locate all instances where the standard message was 
used, make the changes and test (.he changes for correctness. This may be a 
very difficult task. 

It may be unwise to combine multiple applications into a single script if 
the applications bekvg to different departments. TK. is often done to reduce 
the cost of the hardware, although the complications that this can cause may 
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result in expenses greater than those for additional hardware. The primary 
problem is if one of the applications fails to operate properly, and it gets to the 
point that the voice response unit needs to be stopped during the day for repairs, 
then all the processes within the script are out of operation until the repairs are 
made. There are some ways to get around this; however, they are not foolproof 
or necessarily easy. 

It is not always, however, a bad idea to combine applications into one 
script. Consider situations where the application is small and requires little 
script code. You may be able to tack this on with a larger one; or combine 
some that can be stopped during the day and left off-line until evening. It must 
be pointed out though, that the ramifications of combining multiple applications 
into a single script need to be carefully examined. 

In our application, we initially had the Accounts Payable and Travel 
Audit, Student Accounts and Payroll applications together on the same module. 
The Accounts Payable and Travel Audit application was the first to be used. 
With the Accounts Payable and Travel Audit application on-line, work was 
being done on the Student Accounts application. Problems occurred when part 
of the script was changed in the Student Accounts script, not realizing the effect 
on the Accounts Payable and Travel Audit section. After several similar 
occurrences, it was decided to install each office's application on separate 
modules. 



Installation Timeline 

August, 1990 Purchasing requisition prepared. 

December, 1990 Voice Response Unit delivered. 

February, 1991 Vendor representative spends one week 

installing unit and also providing limited in- 
house training. Extensive work done on the 
script at this time. 

April, 1991 Administrators of the unit attended intensive one 

week training at vendor home office. 

September, 1991 Accounts Payable application goes "LIVE." 

Initial Community Reaction 

We previously mentioned that the image of the Accounts Payable and 
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Travel Audit Office was very poor. Installing this voice response unit, initially, 
did not help this situation. Many people despise voice response units. We 
received numerous complaints. 

One of the problems we had was the time it took our telephone 
representatives to get to the callers on hold after they had gone through the 
voice response unit process. There are eight telephone lines coming into the 
voice response unit. Initially, we had two service representatives signed into 
the telephone group at any given time, with a queue of five callers waiting to 
talk to a service representative. The total number of callers at any given time 
would be a maximum of 15 (eight callers using the voice response unit, plus 
five that have been through the voice response unit, elected to speak to a service 
representative and on hold waiting for the next available representative, plus 
two talking to the service representatives). We started getting complaints of 
people being on hold for LONG periods of time. We underestimated the length 
of time it takes our service representative to handle a call. The voice response 
unit is quick, and when it was done and the caller wanted to be transferred, the 
caller would get in line in the queue of five. This queue was later reduced to 
two. This cut down the complaints. If the queue is full when the voice 
response unit tries to transfer a call, they get a message instructing them that all 
operators are busy and they will need to call back later. 

We also added music for people waiting in the queue to talk to a service 
representative. This let the caller know that the unit didn't hang up on them. 

Many people simply said "I hate it!" While others had very positive 
comments. It took about six months to educate enough callers. The service 
representatives spent much of their time "teaching" the callers that they could 
have gotten this information much quicker by using the voice response unit. 
The number of complaints has significantly reduced over the last six months. 
One of the initial responses said that "once I LISTENED to the instructions it 
was a very easy system to use." Most people do not listen very well, and this 
was the brunt of the problem, initially. Many people thought that this may be 
just an experiment that will go away if they complain long enough and loud 
enough. It's critical to have the support of your executive officers, because 
they WILL get complaints! But if you hang in there, and ensure callers that this 
system is here to stay, the noise level will diminish. 

Future Possibilities 

Currently, our phone system does not always detect that a caller has 
hung up. This causes the voice response unit to execute a time-out routine. 
This skews the statistics incorrectly, causes line congestion, and transfers calls 
with nobody holding on the line. To get around this situation, we developed a 
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"weak" routine to detect the situation when a caller is still on the line. When 
our telephone equipment software is updated to industry standards, this weak 
routine can be removed. 

We plan to include a pager routine to page the support person or group 
when the mainframe is down or an excessive number of predefined 
circumstances occurs (unmatched or unrecognized screens). 

All of the telephone lines used by the voice response unit were defined 
with call transfer. This causes a conference call mode to be set when 
transferring a call. This option needs to be removed, along with the code 
required to get around the conference calling option. 

Many vendors call our office asking for basic information on how to get 
their invoices paid by the University. Another application would be to construct 
a series of instructions for callers to access to obtain basic information, for 
example; "Where do I send my invoice?" 



Would We Do It Again? 

The Accounts Payable and Travel Audit application has been on-line for 
more than a year. When asked if we would do it all again, the answer would be 
yes. That's not to say we haven't had problems. We have; some have already 
been mentioned! There are some things that we would do differently. 

We mentioned earlier that the vendor sent a representative to install the unit 
and do some in-house training BEFORE we had formal, intensive classroom 
training. This should have been reversed. We found ourselves scrambling 
to write a script of our application when we had very little background 
knowledge of the system itself. The week long training at the vendors home 
office provided us with enough information to have a much more thorough 
understanding of the system. 

One of the problems we mentioned earlier was trying to mold three 
applications from three different offices into one system. This was a 
mistake. We have recently split the applications onto three separate 
modules, but many problems could have been avoided if this been done in 
the beginning. The vendor recommended incorporating the applications into 
one; however, they didn't understand the "politics" that can occur at a 
university. 

At the same time we were working on the installation of the voice response 
unit within the Accounts Payable and Travel Audit Office, many other 
systems changes were being prepared. Our old system did not assign a 
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paydate when the invoice was initially audited. One of our system 
enhancements that came later was the paydate being assigned when the 
invoice went through the actual audit step. This change was not 
implemented until November, 1991. Remember, the Accounts Payable 
application on the voice response unit went "live" in September, 1991. We 
had two months of many calis being transferred to the service 
representatives when the invoice had been successfully audited but the voice 
response unit could not give a complete answer. Also, when our other 
changes were implemented in November, 1991, the learning curve proved to 
be quite steep and our office got behind which caused frustration on the part 
of callers because they had to wade through a new voice response unit only 
to find out that their invoice had not been processed. We should have 
waited for our new system to be implemented and for the office to be in a 
current status. We were too rushed to implement the voice response unit. 

The vendor emphasized the need for a system administrator, one person who 
would be assigned the responsibility to know the complete voice response 
unit system. We underestimated the need for this, especially since the unit 
was being shared by more than one university department. We now have an 
administrator for the unit who is responsible for making any necessary 
changes to the voice response unit itself. The departments who have an 
application then provide key individuals to write the script and provide 
technical assistance to the administrator. The administrator then goes in and 
programs the unit. 

When the initial discussions took place about purchasing a voice 
response unit, we said we would be happy if the unit would be able to 
completely handle one-third of all the calls into the Accounts Payable and 
Travel Audit Office. Statistics show that the unit receives an average of 350- 
400 calls per day. Of these, 200 callers are transferred to the service 
representatives. This means that approximately 40 percent of all calls are being 
completely handled by the voice response unit. 

The University of Michigan spent about $120,000 for this unit, including 
the in-house training and installation of the product. Remember, this unit is 
shared by four departments with four different applications, about $30,000 for 
each department. This is the cost of one service representative (including staff 
benefits) for one year. We think we made the right move! 
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What is Forms Processing? 

We all know what a "form" is. Or do we? Most would 
probably agree that it's usually a pre-printed piece of 
paper that one must fill out in order to request something 
(for example, a credit card application). Or it can be an 
official notification from one office to another office (for 
example, a registrar notifying the housing office that a 
student has withdrawn from school). 

But a "form" is more than a piece of paper. It is a 
process. It involves sending the form to appropriate 
individuals who will "approve" it. Once acted upon, it is 
important that the originator know the results of the 
request or notification. In some cases the form acts as an 
audit trail by requiring signatures and dates from various 
authorized individuals. 

Forms processing has these components: 

1) A pre-printed "form" that requires that 
information be supplied in a specific format 
by an authorized originator. 

2) A method for sending or routing the "form" to 
authorized individuals for their acceptance or 
rejection. 

3) A way to track the progress of the form so that 
all appropriate individuals can check the status 
of the form at various points in time. 

The Problem with Paper Fo rms 

Paper forms served us well in a society where time wa:, 
measured in weeks instead of minutes, where communication 
was done via the postal service, and where the system 
assumed that some forms would be lost in the mail ol 
inaccurately filled in. 

But we now live in an age where every second counts, 
where we communicate via computer and fax machines, and 
where inaccuracy is less tolerated. 
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Electronic Forms - How They can Help 

By using our computers instead of paper, we can mimic 
traditional forms processing as well as greatly improve the 
accuracy, timeliness, and routing of forms. 

If we "paint" the traditional form on our computer 
screens, we can "edit" each required field as the originator 
enters the data. Unlike paper forms, we can catch errors 
before the form is sent. 

Because we will send the form electronically, it will 
be delivered in seconds, not days. 

People receiving the form can act more quickly on it 
because they know that the data has been checked before they 
receive it. Delays due to incomplete or inaccurate 
information are virtually eliminated. 

An electronic audit trail is available so that the 
originator and all subsequent approvers can view the status 
of the form without having to make phone calls or send 
letters . 

Since paper forms are no longer needed, there is no 
need to spend money to order, store, and distribute forms. 
No longer will there be horror stories about having to toss 
out boxes of forms because the format has slightly changed. 



Originating an Electronic Form 

At Boston College a form can be originated by any user 
of the administrative system ( IBM CICS). A simple menu is 
presented : 



1 Originate a Form / View Available Fnrms 

2 View the Forms Originated by Our Department 

3 Approve the Forms Awaiting Our Attention 

4 View the Forms Previously Approved by Our Dept 
Q Quit - Return to System Menu 

L Logoff 



INTER-OFFICE FORMS 



DATE: MAY 1,199 3 
NAME: J. DOE 



SELECTION: 
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After selecting option "1", the screen displays the 
various categories or forms that this user can originate: 



FORMS ORIGINATION MENU 



DATE: MAY 1,1993 
NAME : J . DOE 



ENTER CATEGORY NUMBER, 
FORM NAME , OR "Q" TO QUIT: 



1 

2 
3 
4 
5 
6 



ADMISSIONS 

BUILDINGS AND GROUNDS 

HUMAN RESOURCES 

LIBRARY 

REGISTRAR 

STUDENT ACCOUNTS 

etc . 



After selecting option "5", the screen displays the 
registrar forms that this user is authorized to originate. 
It is important to note that some of the forms are 
"requests" from the registrar's office (available to a wide 
range of people), and others are "notifications" from the 
registrar's office (limited to registrar personnel) • In 
this case, assume that the user is on the registrar's staff. 



ORIGINATE A FORM 
REGISTRAR 



DATE: MAY 1,1993 
NAME: J. DOE 



ENTER FORM NUMBER, 

FORM NAME, OR "Q" TO QUIT: 



Num 



Form 



Description 



1 
2 
3 



STADDR 
STMAJOR 
STWITHDR 
etc . 



CHANGE OF STUDENT ADDRESS 

CHANGE OF STUDENT MAJOR 

STUDENT WITHDRAWALS NOTIFICATION 
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Option "3" is selected and the screen displays a form 
that allows the registrar to notify student accounts, 
housing, financial aid, and other departments that students 
have withdrawn from the university. Note that the ID number 
is the only required field that must be entered. All 
additional information is retrieved from the student file. 

When this form is completed, it will automatically be 
sent to all of the destination departments. 



Students Withdrawn From School 

ID NAME City St Zip School 

123456789 JONES , MARY BOSTON MA 02135 ARTS/SCIENCES 

928776321 SMITH, THOMAS NEW YORK NY 10010 ARTS/SCIENCES 



EFFECTIVE DATE: 05/01/1993 



Approving/Receiving an Electronic Form 

Filled in forms are routed to departments. Based on 
security codes, only certain positions in the destination 
department can process the form. 

An individual in a housing office position that has 
authority to process a form will see a list of "pending" 
forms when the option "APPROVE FORMS AWAITING OUR ATTENTION" 
is selected from the main menu: 



FORMS TO BE APPROVED 



DATR : MAY 1 , .1.093 
NAME : B . ronpF.r 



Selection 



Num Form 

1 STWITHDR 

2 etc 



(A=Approve, V-View, P=Print, X=Cancel, Q=guiU 



Requ i red 
Orig Date Action 
05/01/1993 PRINT 



<-Last Processor Info — > 
Status Date Process 
ORIG 05/01/1993 J. DOE 
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When "A 1" is selected, the form is flagged as approved 
and sent to further destinations (if any). Furthermore, the 
forms can be sent to a local printer or sent to an on-line 
transaction for further processing* In the above example, 
the form is sent to a printer* 



System Design 

The forms system runs on CICS using an IBM 3090. It 
has been designed so that all forms, routing, and security 
are table driven. In addition, utility programs have been 
developed for programmers to quickly "paint 11 new forms and 
associate edits with fields on the form. 

All forms (screens) and associated edits are stored on 
a file when the form and its documentation is "checked in" 
by the programmer. Regardless of the number of forms 
developed, there is no need for further CICS transactions I 
All screen napping and process logic is controlled by one 
basic transaction. Developing or changing forms is much 
faster than traditional programming. 

Although not all possible edits can be performed on 
each input field, the edits are quite rich. Edits fall into 
these categories: 

1) Basic Edits 

a) Automatic initialization of specified fields 
to date , time , user name , etc . 

b) Check if field is required or optional 

c) Check for numerics, blanks, etc. 

d) Edit money with decimal places, signs 

e) Edit dates and times in various formats 

2) Table Edits 

a) Compare a screen value to any of our online 
tables (containing valid codes and descriptions) 

b) Display description from online table 

3) File Edits 

a) Ability to key any CICS file record and 
return any record field for display on screen. 

b) Ability to display fields based on logical 
"truth conditions" 

4) Comparison edits 

a) Ability to compare the values of two input fields 

b) Ability to compare value of input field to the 
present date, time, and other system fields. 

5) "Jump" Logic to Non-form Screens 

a ) Ability to "jump" to another screen to retrieve 
data when user is unsure of values to enter. 



Security and Routing Control 



The Security administrator works closely with the 
programmer and the user to determine the security access to 
the forms and the routing to the various departments. 

Security access is based on the same access codes we 
use for access to other CICS transactions. For example, 
there may be a security code for "Registrar - Updates 1 ' . A 
form that can be processed by the same group of people will 
simply be assigned the same access code. However, a form 
can be further limited to specific positions, although it is 
usually not needed. 

Each form can be routed through a maximum of nine 
departments. The form cannot proceed to the next level of 
approval until all departments on the same level have 
approved the f orm . A simple route can be one-to-one : 

A — > B — > C — > D 

Department B does not receive the form until Department A 
has approved it. Likewise, Department C must wait for 
Department B, and D must wait for C. 

In some cases , a department wants to simply noti fy 
several departments all at once. Routing is one-to-many: 



B 

/ 

A — C 

\ 

D 



In the above case, Department A routes the form to 3 
different departments at the same time. Departments B, C, 
and D are not dependent on each other. 

Combinations of one-to-one and one-to-many are 
permitted: 

D 

/ 

A — > B — > C — > F 

\ 

E 

In the above example, Departments D , E , and F all ie':«ii 
the form as soon as Department C approves it. 

In the following routing scheme Department G must wait 
until Departments D, E, or F approves the form: 



D 

/ \ 

A --> B -~> C > F -~> G 

\ / 
E 
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Impact of Electronic Forms on Workplace 



When people started getting electronic mail, it started 
changing habits. People started "opening the mail" as part 
of their usual logon procedures. 

Electronic forms have a similar effect. The list of 
pending forms acts as a "To Do" list of daily tasks. On 
most days there are not a lot of forms. But on the days 
where there are many pending forms of a different nature, 
the individual is able to quickly browse the list (much like 
scanning "mail") and determine which are most urgent. 

The number of phone calls have been reduced. Since all 
parties can see the routing list with the approval dates and 
times, there is less of a need for frantic calls. On the 
other hand, "lost in the mail" is no longer an excuse. 

Shortcuts used to be taken because everyone agreed that 
paper notification was too slow. But sometimes the 
after-the-fact notifications resulting from shortcuts 
resulted in wasted money and effort. if communication is 
fast and accurate, the need for shortcuts will be reduced.- 



Impact of Electronic Forms on Students 

Although students have special "front ends" to access 
the administrative system, they too use electronic forms. 
One of the most popular is the change-of -address form. 
While students are using workstations to register 
themselves, they can choose a menu option that allows them 
to notify the college of a change of address or phone 
number. 



Forms versus Direct Updates 

Forms are not the answer to all inter-departmental 
communications. In some cases it may be appropriate to 
allow direct update of one department's data by another 
department. With tight enough edits it may be just as valid 
for the "other" department to do the updating without an 
"approval" from the owner department. 



Conclus ion 

Electronic forms processing at Boston College has 
allowed inter-office information to be routed faster and 
more accurately than ever before. It has improved 

productivity of offices and improved the service that we can 
offer students, faculty, and staff. 
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Background 

Clcmson University is an institution of higher education established by the citizens of 
South Carolina to preserve, enhance, interpret, and disseminate the body of human 
knowledge. As a publicly-assisted, comprehensive land-grant institution, Clemson serves the 
state, the nation as a whole, and the international community through teaching research, and 
public service activities. 

To fulfill its mission, Clcmson offers undergraduate and graduate programs within nine 
colleges and a graduate school to a diversified on-campus student body and to a variety of 
audiences through continuing education courses on and off campus. The institution's role 
within the State of South Carolina is fulfilled through its mandated thrusts in agriculture and 
natural resources, architecture, engineering, textiles, basic sciences and technologies and 
through an expanded role which also addresses the state's cultural and economic needs 
through emphasis in health services, business, education, and the liberal arts. Clemson 
University's response to public services is reflected through the expertise of each of nine 
colleges, the S.C. Agricultural Experiment Station, the Clemson University Cooperative 
Extension Service, and numerous regulatory programs which provide technical assistance, 
continuing education, technology transfer, and extension activities commensurate with life in a 
changing world and global society. 

Clems-on University is located in the northwestern corner of South Carolina. The campus 
proper consists of 1,400 acres surrounded by 18,000 acres of University farms and woodlands 
devoted to research. Approximately two-thirds of these across the state are devoted to 
agriculture extension and 4-H work. Graduate and undergraduate enrollment for the 
University is approximately 16,000. These students are supported by slightly over 4000 
full-time faculty and staff, and an annual budget of $300 million. 

The growth and diversity of the University, as well as changing authoritative accounting 
standards, state and federal reporting and operating requirements, and the increasing 
competitiveness for students and research dollars are some of the drivers of the new 
information needs at Clcmson. 
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Financial System Environment 

The current University administrative systems were developed in-housc about 15 years 
ago. They arc maintained by a centralized team of programmers, analysts and database and 
security administrators. The accounting system is one facet of the whole package. The original 
system requirements were developed in conjunction with University accounting and budget 
office personnel based on their definitions of needs and the existing reporting environment. 

The cornerstone of the system is a seventeen digit account number with some intelligence 
included. Six individual fields with varying lengths comprise this number (Exhibit A). A 
general ledger module posts detail and summary transactions to these accounts. Other 
modules such as payroll and a vendor check processor feed the central module. Posting occurs 
after a nightly process run in batch mode. 

Originally, standardized reports formats were defined by the users and were produced by 
production jobs run at the central data center on a monthly basis. These reports were 
available primarily to the central administration. Since 1975, many enhancements have been 
made in all modules. Some of these include 

• expanding on-line access of information to end-users, both for on-line query and on-line 
report requests 

• allowing on-line update of information by the departmental users with real-time, not batch 
update 

• processing documents via electronic forms with on-line approvals. 

Management Information Solutions 

Facing the changing information requirements of users, Clcmson began some years ago to 
search for a workable solution. A system study done in conjunction with a major vendor 
sought to outline users' needs. This was the springboard for a later system analysis which led 
to the development of a detailed request for proposal This request resulted in several vendor 
presentations of overall accounting system packages. However, with no one vendor offering a 
total solution, and with anticipated reductions in State funding, the option to purchase new 
software and hardware was not feasible. The alternative option of totally redesigning the 
existing system was not selected due to currently limited internal programming resources. 

The next best alternative was to find a solution which could affordably meet reporting 
needs in as timely a manner as possible. Research continued to be done on what other colleges 
and universities were using to meet their needs. Clemson was operating on the theory that 
college and university operations and reporting were so unique that only a solution made for 
higher education could work. This premise was proven wrong when university personnel were 
introduced to a PC based reporting software solution developed by IMRS. Their products are 
currently used to meet reporting needs of many Fortune 500 companies. The basic reporting 
requirements for Clemson, even though they appear to be different, arc basically the same as 
any large business operation. Common needs include the ability 

• to report in a timely manner 
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• to report in various formats defined by the user in a "friendly" environment 

• to adjust the data for proposed changes in M what-iP scenarios 

• to report at various levels within the organization and be able to "drill-down" to desired 
levels of detail 

• to report in multiple organizational structures without repeating the same core data. 

As the IMRS software had successfully addressed these same issues in the corporate 
arena, Clemson made the commitment to purchase management information reporting 
software. This action was seen as a way to increase user satisfaction and productivity with less 
of a financial commitment than a total system overhaul, less drain on mainframe programming 
resources, and less disruption to normal processing and work schedules. 

The IMRS company markets component products which meet the University's needs, 
The database piece houses all the information in the appropriately user defined reporting 
relationships which forms the core of the system. Regular printed reports arc created in this 
software and the on-line query and display features of the product reside here. An executive 
information system (EIS) piece draws the information from the database and presents it in 
standard chart or graphical formats. 

The database piece is called Micro Control. This is where the flexibility and reporting 
functionality lie. The design of the reporting relationships and definition of detailed data are 
critical to allow information extraction later. It is DOS based. The EIS piece, On-Track, is 
Windows based and provides the GUI features that many users have come to expect. 

Solution Implementation 

Clemson began a phased implementation of the products by choosing one application to 
design and have functioning in a relatively short period of time. A critical need of the 
University was to be able to produce financial statements in a timely manner. Therefore, phase 
one of the IMRS implementation was to produce financial statements for Clemson University 
by June 30, 1902. The project began January, 1992. This phase included 

• design of the organizational structure (Exhibit B) 

• definition of the chart of accounts (Exnibit C) 

• coordination of the move of data from mainframe to PC 

• configuration of network and PC hardware 

• creation of specific financial reports (Exhibit D). 
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The implementation team for Micro Control was really a triumvirate. A three person 
Administrative Programming group who maintain the mainframe general ledger system, a 
three person network administration group in the Business and Finance area who maintain 
network and PC systems, and a four person financial group with experience in the mainframe 
application system and the financial reporting requirements. Cooperation and coordination 
between these groups was essential to the successful implementation of the product. 

Three of the financial group attended a week of vendor training to learn the details of 
Micro Control. Then, meeting with consultants from the vendor, the initial structures and 
chart of accounts were defined. Software was loaded onto the network and prototyping the 
system began. 

The source of all the information for Micro Control is the existing mainframe general 
ledger. It runs on a large Hitachi mainframe which is centrally maintained by the University's 
Division of Computing and Information Technology (DCIT). Micro Control itself runs on a 
Novell network. All data and program files are loaded onto a separate drive and use 
approximately 60 megabytes of space. 386 and 486 PCs have both been used to operate Micro 
Control with satisfactory performance results. 

Each night, after batch posting of the general ledger occurs on the mainframe, an extract 
of all data is created by production jobs. This is the file that is vital to Micro Control. 

A set of conversion tables was created by the financial group which defines the 
relationship of the mainframe system account number to the Micro Control account and 
component. COBOL programs, written by the administrative programming group, call these 
tables, apply them to the nightly extract file and produce a dataset in the correct format for 
Micro Control to read and load into its database. Conversion takes place on the mainframe 
side to take advantage of the processing power there. Over one million records are on the 
extract file by the end of the fiscal year. These are all read and condensed from approximately 
300,000 accounts to approximately 1200 accounts on the PC software. 

The following sequence of events takes place to move the data from mainframe to PC: 

During overnight processing as part of regular production job stream 

• mainframe financial system posts transactions 

• mainframe extract file is created 

• conversion programs run and create mainframe dataset in Micro Control file format. 
In the morning in the Accounting office 

• Micro Control file is checked for comparability with mainframe data (e.g.. has all account 

maintenance done on mainframe side been reflected on PC side) and any corrections to 
the PC side are made 

• file is downloaded to Novell network 
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• file is loaded into the correct time period and category (i.e. Actual or Budget, etc.) in 
Micro Control 

• a consolidation process is started in Micro Control to summarize the appropriately defined 
sub-totals 

• reports arc printed and data is available on-line for inquiry. 

At this point, the cycle is complete from the standpoint of movement of data. Now the 
end-user can began to use the information on-line, request standard reports, such as the 
financial statements, which have been pre-defined, or using the Micro Control report builder, 
create their own reports. 

For more flexible and dramatic presentation formats, the EIS piece is the appropriate 
vehicle. Files in On-Track reference account numbers in the database and the values of these 
accounts are then presented on-screen. As new information is updated in the database it is 
reflected in the on-screen presentation. On-Track gives the user the capability of moving from 
a total figure on the screen to multiple lower levels that compile the figure. Numbers can be 
graphed and notes and accompanying information can be inserted onto the screens for the 
user's edification. All movement between screens is mouse driven. 

The technical operations of the mainframe and PC systems were synchronized and the test 
financial statement were produced by May, 1992. Significant testing then followed to ensure 
the accuracy of the data. 

Implementation Results 

Immediately upon the closing of the books for the 1992 fiscal year, Micro Control 
produced financial statements for the University and phase one ended successfully. The 
essential GAAP (generally accepted accounting principles) financial statements for colleges 
and universities arc : the Balance Sheet, the Statement of Changes in Fund Balances, and the 
Statement of Current Funds Revenues, Expenditures and Other Changes. Previously, utilizing 
only the University's existing general ledger, these basic statements took upwards of six weeks 
to compile, Data had to be summarized considerably, and was often reformatted in ord^r to 
produce these statements. It was an intensive, hands-on manual operation requiring 
piece-meal downloads from the mainframe, manipulation of the data utilizing commercial 
spreadsheet packages to produce trial balances, and re-keying of this data into final product 
financial statement format. Besides the obvious time and effort drawbacks inherent in this 
process, it was extremely inflexible; posting audit adjustments or reformatting the statements 
for other reporting entities was a massive undertaking. Basically, a change request required 
financial reporting personnel to repeat the original arduous process. 

Also, immediately available were alternate and subsidiary reports developed for other 
reporting entities. The Statement of Changes in Unrestricted Fund Balances (Exhibit D, Page 
2), for example, segmented information from the Statement of Currevit Funds Revenues, 
Expenditures and Other CLmgcs into Basic Educational and General, Auxiliary and 
Agricultural Public Service Components, Thus, the University had across-the-board financial 
reporting capability at the earliest possible date. 



In addition to producing "instant" year-end financial statements, the University realized 
other tangible benefits from the information solution. 

The relative ease and flexibility in downloading comprehensive data from the mainframe, 
for the first time, makes it possible to issue interim financial reports. Financial data is 
downloaded on a weekly, and sometimes even, daily basis, to provide administrators and 
managers up-to-the-minute performance information. 

The new database also allows for more sophisticated reporting in the endowment and 
plant funds, The University's general ledger design did not anticipate the need for the 
multiple funds existing in today's accounting environment, Consequently, the Permanent, 
Quasi and Term Endowment Funds are all rolled into one fund group in the general ledger. 
Likewise for plant funds, Unexpended, Renewals and Replacements, Retirement of 
Indebtedness and Investment in Plant funds arc grouped as one. These individual funds arc 
restricted in nature and arc required by GAAP to be accounted for separately, The Micro 
Control database literally splits the existing general ledger "holding funds" into the proper 
categories. The result is a Statement of Change in Fund Balances and a Balance Sheet for 
each of the separate funds. 

This enhanced financial reporting capability has served University administration well thus 
far. However, it is also bringing to the forefront some quality issues and causing a 
reassessment of some financial strategics. 

For example, Clemson is increasingly focusing its efforts in research initiatives. The 
majority of research grants at the University operate on a cost reimbursement basis (e.g. the 
research is done and expenses made, then Clemson bills the sponsor and receives payment 
after the fact). The ability to examine sponsored program cash balances weekly, or even daily, 
on an aggregate basis instead of project by project led to better cash management practices. 
These included more aggressive collections procedures, negotiating scheduled payment 
contracts and increased use of electronic funds transfer. 

Also, it has forced a look at the traditional annual reporting cycle. Many University-wide 
charges, such as internal computer usage or general and administrative charges assessed on 
campus profit centers were formerly recorded in lump-sum once a year. State appropriations, 
usually in excess of $100 million were recorded in a similar manner. With the advent of 
University level interim financial statements, these once a year entries proved distorting. The 
result has been to book these items on a pro-rated or per-capita basis, thereby providing more 
meaningful information to administration. 

Overall, phase one of the implementation has proven imminently successful. The desired 
short-term goal, production of the University GAAP and other year-end financial statements 
was met. In addition, interim financial statements, and other reports developed since have 
resulted in inn-eased efficiencies and improvements in meeting the planning and fiduciary 
responsibilities of the University. 



Future Goals 



With the integrity and accuracy of the Micro Control database firmly established, repeated 
requests for detailed, specialized reporting are being received. The Office of the Provost has 
requested summary financial reports which accumulate data for all academic departments. 
The Public Service Division plans bi-weekly reporting for budget monitoring and reporting 
based on the Federal fiscal year which differs from that of the University. 

Considerable attention has been given to each of these requests as well as other aspects 
for the future. Broadening the on-line access to Micro Control and On-Track is essential in 
the continued success of the implementation. This will require end-user training and 
education so that the full potential of the available information can be realized. The 
immediate goal of the implementation team is to incorporate budget information into the 
existing database which is populated with actual figures. This will provide the ability to 
provide traditional budget vs. actual type management information; in the current budget 
environment this should prove particularly helpful. 

Summary 

Clemson is quite pleased with the solution it has implemented to meet some of its 
management information challenges. A purchased package which feeds on the massive data 
and processing power of the mainframe is serving us well, and has great potential for future 
applications. Surely, this will not be the final solution for providing management information; 
daily, needs change and new technologies and products bring more power closer to the end- 
user. Regardless of the mechanism, getting the information into the hands of those who make 
the decisions is the ultimate solution. 
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GAAP REPORTING 
CURRENT FUNDS 

CURRENT UNRESTRICTED FUNDS 
EDUCATIONAL AND GENERAL FUNDS 
GENERAL 

E&G REPORTING 
GENERAL - STATE 
GENERAL - STATE 



* * 

| N0501 | Dean of Architecture 

* * 

| N0503 | Architectural Studios 
* * 

| N0507 | Building Sciences 
* * 

•| N0509 | Visual Arts and History 
★ * 

-J N0511 | Planning Studies 
* * 

-j N0590 | Centers for Arch. Studies 
* * 

-j N0701 | Dean of Education 
* * 

-j N0702 | Associate Dean of Educat i< 
*__ * 

-j N0703 | Military Science 
* * 

-j N0705 | Aerospace Studies 

* * 

-j N0709 j El em and Secondary Ed 

* * 

-j M0711 | industrial Fd 
* ~ _ . * 

-| N0901 | Dean of Engineering 



/> '^RT OF ACCTS (CLEMSON UNIVERSITY.) 
DATE: 7/29/92 

**************************** ***************** 

OPTION ALPHA 

GROUP 1 !*** NON- FINANCIAL *** 
i ********************************************* 



************************************************ 

HEADINGS FILE 



EXHIBIT C 

**************************^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
GROUP 1 **** NON' FI NANCIAL *** 

*********************************************** ## ^^^^.^^ 



ACC=A1111 
ACC=A2222 
ACC=:A3333 
ACC=A4444 
ACC=A5555 
ACC=A6666 
ACC=A777P 
ACC=A777Q 
ACC=A777T 
ACC=A8ROI 
ACC=A88RR 
ACC=A8UNX 
ACC=A8INV 



ACC=BINV2 



JOURNAL ENTRY ACCOUNTS 
! ! 

1A1111 "JE FG1" 

U2222 "JE FG2" 

IA3333 "JE FG3" 

(A4444 "JE FG4" 

!A555S "JE FG5" 

IA6666 "JE FG6" 

\M77? "JE FG7P" 

1A777Q "JE FG7Q" 

IA777T "JE FG7T" 

IA8ROI "JE FG8ROI" 

IA88RR "JE FG8RR" 

! A8UNX "JE FG8UNX" 

IA8INV "JE FG8INV" 
t I 



*** I 

! 
! 

***! 

! 
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INVENTORY ACCOUNT-AUXILIARIES 
"BEGINNING INVENTORY" 
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ACC=20060 
SUB=10, 20,98 
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120030 
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120040 
120040.10 
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!?0040.98 
! i 
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120050.10 

I20050.20 

120050.98 
I | 

120060 
120060.10 



REVENUES AND OTHER ADDITIONS: 

"STUDENT FEES" 

''Academic Fees" 

"Summer School Fees" 

"Laboratory Fees" 

"Short Courses and Seminars" 

"Other Student Fees" 

"Holding" 

"FEDERAL APPROPRIATIONS" 

"STATE AND LOCAL APP" 

"FEDERAL GRANTS AND CONTRACTS" 
"Federal Grants and Contracts" 
"Indirect Cost Recoveries" 
"Holding" 

"STATE GRANTS AND CONTRACTS" 
"State Grants and Contracts" 
"Indirect Cost Recoveries" 
"Holding" 

"LOCAL GRANTS AND CONTRACTS" 
"Local Grants and Contracts" 
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EXHIBIT D 



Cash and cash equivalents 
Accounts receivable 
Inventories 
Prepaid expenses 

Due from restricted current funds 



TOTAL E&G 



CLEMSON UNIVERSITY 

BALANCE SHEET- UNRESTRICTED CURRENT FUNDS 
YEAR ENDED JUN/92 Page: 1 



ASSETS 



2,206,125 
1,081,225 
562,953 
2,129,912 



5,980,215 



Accounts payable 
Accrued liabilities 
Deferred revenues 
Student deposits 
Accrued vacation 
Fund balance (deficit) 

TOTAL E&G 



LIABILITIES AND 
FUND BALANCES 

233,468 
2,197,970 
2,307.370 

360,007 

881,399 
5,980,215 



Cash and cash equivalents 



Accounts payable 
Accrued liabilities 



TOTAL CLEARING 
TOTAL 



TOTAL CLEARING 
5,980,215 TOTAL 



5,980,215 



Cash and cash equivalents 
Federal G&C Receivable 
Accounts receivable 
Inventories 
Prepaid expenses 

Due from restricted current funds 



200,075 
1,088,689 



30,261 



Accounts payable 
Accrued liabi lities 
Deferred revenues 
Student deposits 
Accrued vacation 
Fund balance (deficit) 



66,526 
1,241,649 
1,652 
9,199 



TOTAL PSA 



1,319,025 



TOTAL PSA 



1,319,025 



Cash and cash equivalents 
Accounts receivable 
Inventories 
Prepaid expenses 

Due from restricted current funds 



TOTAL AUXILIARIES 



15,427,779 
1,446,460 
2,560,667 
334,758 
26,329 



19,795,993 



Accounts payable 
Accrued liabilites 
Deferred revenues 
Student deposits 
Accrued vacation 
Due to other funds 
Fund balance (deficit) 

TOTAL AUXILIARIES 



656,763 
429,844 
6,184,668 
898,709 

26,329 
11,599,680 

19,795,993 



TOTAL 



27,095,233 TOTAL 



27,095,233 
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CLEMSON UNIVERSITY 
STATEMENT OF CHANGES IN UNRESTRICTED FUND BALANCES 
YEAREND JUN/92 Page: 2 





BASIC 
EDUCATIONAL 
AND GENERAL 


AUXILIARIES 


AGRICULTURAL 
RESEARCH 


COOPERATIVE 
AGRICULTURAL 
EXTENSION 


FOREST AND 
RECREATION 
RESOURCES 


REVENUES: 

Student fees 

Federal appropriations 

State and local appropriations 

Federal grants and contracts 

State grants and contracts 

Local grants and contracts 

Private gifts, grants and contracts 

Endowment income 

Sales/services of educational departments 
Sales and services of auxiliary enterprise 
Computer and systems developement 
Other sources 


57,186,931 
25,000 
76,358,527 
3,125,707 
18,797 
1,467 
990,467 
9,266 
70,145 

5,005,575 
3,477,536 


60,307,381 


3,624,151 
15,326,925 

686,512 
3,264 


7,942,894 
19,063,852 

729,520 
787 


376,275 
2,343,719 

313,798 
5,112 


TOTAL UNRESTRICTED CURRENT REVENUES 


146,269,418 


60,307,381 


19,640,851 


27,737,053 


3,538,904 


EXPENDITURES AND MANDATORY TRANSFERS: 

Educational and general: 
Instruction 
Research 
Public service 
Academic support 
Student services 
Institutional support 
Operation and maintenance of plant 
Scholarships and fellowships 
Departmental actnini strati on expense 


63,391,891 
11,331,529 

3,420,368 
16,250,279 

6,847,274 
15,013,189 
15,921,697 
917,042 
13,751,836 


- 

- 
- 

- 


15,267,008 
- 

3,845,746 


26,430,222 
- 

1,874,982 


C,H**/ ,OcO 

468,700 

■ZTQ 7Q-T 

jjy , / oo 
502,974 


TOTAL UNRESTRICTED E & G EXPENDITURES 


146,845,105 




19,112,754 


28,305,204 


3,759,083 


Mandatory transfers for: 
Principal and interest 
Loan fund matching grants 


24,878 


- 


- 


- 


- 


TOTAL MANDATORY TRANSFERS 


24,878 










TOTAL EDUCATIONAL AND GENERAL 


146,869,983 




19,112,754 


28,305,204 


3,759,083 


Auxiliary Enterprises: 
Expenditures 

Mandatory transfers for: 
Principal and interest 
Renewals and replacements 


- 


54,996,734 
2,857,456 




- 


- 


TOTAL AUXILIARY ENTERPRISES 




57,854,190 








TOTAL EXPENDITURES AND MANDATORY TRANSFERS 


146,869,983 


57,854,190 


19,112,754 


28,305,204 


3,759,083 


OTHER TRANSFERS AND ADDITIONS/(DEDUCTI0NS) : 

Indirect costs recovered 

Indirect costs remitted to state 

Non-mandatory transfers- unrestricted 

Net transfers between funds 

Realized investment losses & other costs 


(213,282) 
(313,099) 


- 

57,888 


- 


_ 

924,413 




TOTAL OTHER TRANSFERS AND 
ADDITI0NS/(DEDUCTI0NS) 


(526,381) 


57,888 




924,413 




NET INCREASE (DECREASE) IN FUND BALANCE 
Fund Balance at Beginning of Year 
Prior Period Adjustment 


(1,126,947) 
2,008,346 


2,511,079 
9,088,601 


528,098 
1,402,691 


356,262 
(2,020,828) 


(220,179) 
(1,718) 


FUND BALANCE AT END OF YEAR 


881,399 


11,599,680 


1,930,788 


(1,664,566) 


(221,897) 
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CLEMSON UNIVERSITY 
STATEMENT OF CHANGES IN UNRESTRICTED FUND BALANCES 
YEAREND JUN/92 Page: 3 





REGULATORY 
SERVICES 


LIVESTOCK 
POULTRY 
HEALTH 


STATE 
ENERGY 
PROGRAM 


BIOENGINEERING 


OTHER 
PUBLIC 
SERVICE 


REVENUES: 

Federal appropriations 

State and local appropriations 

Federal grants and contracts 

State grants and contracts 

Local grants and contracts 

Private gifts, grants and contracts 

Endowment income 

Sales/ services of educp/cional departments 
Sales and services of auxiliary enterprise 
Computer and systems developement 
Other sources 


2,074,891 
83,841 

50,000 
75 


2,351,486 
137,814 

141,924 


114,132 


144,323 


- 


TOTAL UNRESTRICTED CURRENT REVENUES 


2,208,807 


2,631,224 


114,132 


144,323 


- 


EXPENDITURES AND MANDATORY TRANSFERS: 

Educational and general: 
Instruction 
Research 
Public service 
Academic support 
Student services 
Institutional support 
Operation and maintenance of plant 
Scholarships and fellowships 
Departmental aotoini strati on expense 


1,668,804 
479,186 


2,303,216 
297,743 


49,992 
68,360 


146,266 




TOTAL UNRESTRICTED E & G EXPENDITURES 


2,147,990 


2,600,960 


118,352 


146,266 




Mandatory transfers for: 
Principal and interest - 
Loan fund matching grants - 


TOTAL MANDATORY TRANSFERS - 


TOTAL EDUCATIONAL AND GENERAL 


2,147,990 


2,600,960 


118,352 


146,266 




Auxiliary Enterprises: 
Expef ditures - 

Mandatory transfers for: 
Principal and interest - 
Renewals and replacements - 


TOTAL AUXILIARY ENTERPRISES ..... 


TOTAL EXPENDITURES AND MANDATORY TRANSFERS 


2,147,990 


2,600,960 


118,352 


146,266 




OTHER TRANSFERS AND ADD IT IONS/ (DEDUCT IONS) : 

Indirect costs recovered 

Indirect costs remitted to state 

Non-mandatory transfers-unrestricted 

Net transfers between funds 

Realized investment losses & other costs 


(85,928) 


(177,814) 








TOTAL OTHER TRANSFERS AND 
ADDITIONS/CDEDUCTIONS) 


(85,928) 


(137,814) 








NET INCREASE (DECREASE) IN FUND BALANCE 
Fund Balance at Beginning of Year 
Prior Period Adjustment 


(25,111) 
37,158 


(107,550) 
42,308 


(4,220) 
2,187 


(1,943) 
12,845 




FUND BALANCE AT END OF YEAR 


12,047 


(65,242) 


(2,032) 


10,902 






CLEMSON UNIVERSITY 
STATEMENT OF CHANGES IN UNRESTRICTED FUND BALANCES 
YEAR END JUN/92 Page: 



TOTAL 



REVENUES: 

Student fees 

Federal appropriations 

State and local appropriations 

Federal grants and contracts 

State grants and contracts 

Local grants and contracts 

Private gifts, grants and contracts 

Endowment income 

Sales/services of educational departments 
Sales and services of auxiliary enterprise 
Computer and systems developement 
Other sources 

TOTAL UNRESTRICTED CURRENT REVENUES 

EXPENDITURES AND MANDATORY TRANSFERS: 

Educational and general: 
Instruction 
Research 
Public service 
Academic support 
Student services 
Institutional support 
Operation and maintenance of plant 
Scholarships and fellowships 
Departmental administration expense 

TOTAL UNRESTRICTED E & G EXPENDITURES 



57,186,931 
11,968,320 
118,277,855 
3,347,362 
18,797 
1,467 
990,467 
9,266 
1,991,898 
60,307,381 
5,005,575 
3,486,774 

262,592,093 



63,391,891 
29,242,422 
34,291,310 
16,590,062 
6,847,274 
15,013,189 
15,921,697 
917,042 
20,820,826 

203,035,713 



Mandatory transfers for: 
Principal and interest 
Loan fund matching grants 

TOTAL MANDATORY TRANSFERS 

TOTAL EDUCATIONAL AND GENERAL 

Auxi I iary Enterprises: 
Expendi tures 

Mandatory transfers for: 
Principal and interest 
Renewals and replacements 

TOTAL AUXILIARY ENTERPRISES 

TOTAL EXPENDITURES AND HANDATORY TRANSFERS 

OTHER TRANSFERS AND ADDITI0NS/(DEDUCTIONS) : 

Indirect costs recovered 

Indirect costs remitted to state 

Non-mandatory transfers-unrestricted 

Net transfers between funds 

Realized investment losses & other costs 

TOTAL OTHER TRANSFERS AND 
ADDITIONS/CDEDUCTIONS) 

NET INCREASE (DECREASE) IN FUND BALANCE 
Fund Balance at Beginning of Year 
Prior Period Adjustment 



24,878 
24,878 
203,060,591 

54,996,734 
2,857,456 

57,854,190 
260,914,781 



(437,024) 
669,201 



232,177 



1,909,489 
10,571,590 



FUND BALANCE AT END OF YEAR 



12,481,079 
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So You Want to Write a CUMREC Paper? 



Tips for Planning and Presenting 



Normandy Roden 
Curricular Programs Manager 
University of Wisconsin-Madison 
830 WARF Building 
Madison, Wisconsin 53 705 
608/262-6956 
normandy . rodenQmail . admin .wise. edu 



Introduction 

Why write a CUMREC paper? For many CUMREC conference-goers, 
writing and presenting a paper is the natural outgrowth of having 
attended prior conferences. Learning about the experiences of 
other people at other institutions encourages them to want to share 
their own success stories at the next year's conference. other 
presenters, when they first plan to attend the conference, 
immediately consider whether or not their current cr recent 
projects would lend themselves to such a forum. 

From a broker perspective, writing and presenting a paper can 
be personally rewarding, as well as professionally stimulating. 
Writing and presenting is a way of paying back a debt ... a 
learning experience in and of itself. "There is a strong personal 
satisfaction in knowing that your shared information helps others 
in the field do their jobs better." (Gerald W. McLaughlin and Julia 
A. Rudy, workshop on writing for CAUSE/ EFFECT , 1991 CAUSE 
Conference. ) 

The goal of this paper is to encourage you, the reader, to 
become the writer /presenter . By sharing information about the 
CUMREC presentation process, by explaining the relevant timeframes, 
responsibilities, and expectations, the author hopes to enhance the 
likelihood of future participation in this process by conference 
attendees . 
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Background; First, Understand Your Audience 



For whom are you writing? CUMREC is the oldest professional 
association in the United states devoted to computing in higher 
education. Currently hosting its 38th annual conference, CUMREC 
was formed in 1956 as the College and University Machine Records 
Conference ( hence , the acronym CUMREC) and was organized by 
administrative computing staff at Michigan State University. The 
name was changed — to the more current College and University 
Computer Users Conference — by the conference board in 1988, 
although the familiar acronym CUMREC was retained. 

One of the primary goals of CUMREC is to provide individuals 
in higher education with the opportunity to share information on 
computerized information systems, with a special focus on student 
and financial systems. In addition, several other issues relating 
to administrative computing have become the subjects of much 
interest; these include: data management and managerial 
responsibilities, security, conversions to new technologies, and 
sensitivity to end-users. 



First Thoughts: Submitting the 'Intent to Present' 

You think you would like to submit a paper for presentation at 
the next year's CUMREC Conference . . . what do you do? 

Each summer, the host committee for the next year's conference 
coordinates a Call for Papers. The Call is distributed with the 
July edition of the quarterly CUMREC Newsletter to persons on the 
current CUMREC mailing list — i.e., persons who have attended at 
least one conference within the previous three years. Information 
on the Call for Papers is also made available to other relevant 
professional associations. 

Responding to the Call for Papers is a simple process. The 
interested person completes an Intent to Present card (see Appendix 
A) — this card is also included in the July Newsletter. The only 
information requested at this time is the general topic of the 
proposed paper and the author 1 s name, institution, and address. 
The Intent to Present card is due at the host committee office by 
the end of September, in the fall preceding the spring conference. 
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What does it mean to submit an Intent to Present? What 
happens next? Submission of an Intent to Present is not a promise 
to submit an actual paper — it simply indicates interest. The 
host committee responds to all persons submitting Intents, sending 
them: acknowledgment of receipt of the Intent; guidelines for 
preparing written copy; and the deadline for submitting the paper. 
The paper submission deadline generally falls in mid-November. 



The Importance of the Written Word; Developing a Paper 

How do you translate a good idea into a good paper? As you go 
about the business of putting your thoughts down on paper, there 
are a number of points to consider: Is the discussion reliant? 
Is it clear to someone outside my institution? Does it make sense 
to someone outside my field? 

When you have a draft copy ready, it's always a good plan to 
ask at least two other people to read it: one person who is close 
to the project or subject you describe — to see if you left 
anything out; one person who isn't — to tell you if it all makes 
sense. Remember the rules of standard prose (refer to the Chicago 
Manual of Style if in doubt) . The most common writing pitfalls are 
incorrect or missing punctuation; inconsistencies in tense; 
incorrect spelling; and basic errors in grammar (noun-verb don't 
agree, etc.). Other problem areas also exist — for example, 
gender specific language and use of unidentified acronyms. 

Remember to follow the guidelines for written copy sent to you 
by the host committee! These include both specifications of format 
and margin widths and length limitations. If your paper is 
accepted, you will find it far easier to submit final camera ready 
copy if your initial text already conforms to the guidelines of the 
committee. 
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Now, What Does the Committee Think? 



What do THEY do? The Program Committee for the given year's 
conference is responsible for reviewing and selecting the papers 
for the conference, for determining the program tracks that will be 
presented , and for assigning each accepted paper into the 
appropriate program track. The committee has six members: the 
Vice President of the CUMREC Board, the current year's local 
program chair, the next year's local program chair, and three at- 
large members (selected according to interest, as demonstrated in 
the interest sheets available to conference attendees each year). 
The committee members receive a packet of papers to read in early 
December and have about four weeks to read and rate them. In early 
January, the committee members join other committee and Board 
members at the conference hotel site, where they compare 
evaluations and make the final selection. 

Each paper is read by three Program Committee members. Each 
member also scores the paper according to a previously agreed upon 
scale — the average of these scores, along with the evaluations of 
the oral presentations, determines the top papers of the 
conference. In addition to identifying the papers accepted for 
presentation, the committee identifies several alternates — papers 
which will be included in the published Proceedings and which will 
be presented at the conference in the event of a cancellation by an 
accepted paper. 

As appropriate, committee members note editorial and other 
suggestions on the accepted and alternate papers. These 
suggestions and/or corrections are conveyed to the author (s) after 
the program review meeting, in a letter sent out around the third 
week of January. 

Your paper was accepted or selected as an alternate — what do 
you do? Authors of accepted and alternate papers should note the 
comments (if any) of the committee members and revise their papers 
accordingly. Technical corrections and other updates, based upon 
feedback from others who have read the paper, can also be made at 
this time but remember: you should not be making substantial 
changes after committee review. 
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Your paper was rejected — now what? Whatever you do, don't 
give up! Perhaps your topic was not particularly relevant to the 
CUMF.EC conference, but might be better suited to a different 
audience. Perhaps grammatical and other editorial problems 
derailed your paper's progress through committee. Or perhaps there 
were a number of papers submitted on a single or similar topics 
that year, and not all could be accepted. The best advice? — 
Consider any comments made by the committee, ask questions if you 
don't understand, and ask for input to improve: it may be 
appropriate to try again next year! 



Polishing the Written Word: Finalizing Your Paper 

You've noted the updates and suggested revisions of the 
committee — now what does the committee need from you? 
Notification of acceptance is sent in mid-late January. The 
committee will indicate the deadline (generally around mid- 
February) for the submission of several critical items: 

the final, camera ready paper (for publication 
in the Conference Proceedings) ; 

— a 100-150 word abstract, or summary, of the 
paper (for publication in the pocket 
conference brochure guide) ; 

a listing of any audiovisual requirements for 
the presentation (if your needs are not simple 
— e.g. , overheads, slide projectors, 
videotape recorders — you may need to speak 
directly with the local conference staff to 
verify that those needs can be met, and/ or 
arrange to bring your own equipment) ; and, 

brief biographical information on the person 
or persons who will be presenting the paper at 
the conference. The latter information is 
used by the moderator of the session to 
introduce the speaker (s) to the audience. 



Anything else you should be doing at this time? Yes — let 
the appropriate people on your campus know that your paper has been 
accepted — this is an honor! 
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When is Silence Golden? Preparing an Oral Presentation 



How do you translate the written word into the spoken? Ask 
yourself the following: What does the audience need to hear? What 
portions of the written paper should be included in the oral 
presentation? What additional information should be added? (This 
is your time to incorporate any recent, relevant developments.) 
What portions of the written text should be left out? 

Also consider the role that audiovisual supports might play in 
your presentation, asking yourself: What does the audience need to 
see in order to follow the talk? A variety of audiovisual aids — 
slides, overheads, flipcharts, videotapes, audiotapes, computer 
displays, paper handouts — can be successfully incorporated into 
a presentation. Practice using different devices to see which ones 
work best for you. And always — test your materials on a real 
audience to see what works best for them . 

Remember that audiovisual aids lose their effectiveness if the 
visuals cannot be seen, and the audio cannot be heard, clearly. A 
good preliminary test to determine relative legibility of an 
overhead is to stand with the overhead on the floor by your feet. 
If you can*t read it, then neither can your audience! The old 
adage that "less is more" applies here as well; one of the most 
common failings in slide shows is having too much information on a 
single slide. Your point is more quickly made by using phrases 
rather than full sentences, and by keeping the points on each slide 
few in number. 

Remember your time allotment! In general, presentations are 
scheduled in 70 minute blocks — you should budget your time 
accordingly* You will need to allow time for audience questions at 
the end: this can be some of the most valuable time spent in a 
session. You also want to be able to speak in a somewhat leisurely 
fashion: although an audience may like a fast-paced production, 
they don't want to have to concentrate on too-rapid delivery by the 
speaker. 
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Practice in public, arranging at least two (one initial, one 
after feedback) trial presentations at your home institution. Your 
practice audience should include both persons who are and who are 
not close to the project. They can prove to be an invaluable 
resource in terms of identifying problems in understanding, 
hearing, visibility/legibility, flow, and context. They can also 
help you determine the need for handouts and — if used can 
evaluate the effectiveness of those handouts. 

Remember the other unspoken rule of speaking: Don't rely on 
memory alone! Bring an outline or a set of numbered notecards to 
refer to in case you lose your train of thought and can't recover; 
similarly, consider posting a large outline where everyone can see 
it — your audience may like to know where you are in the talk so 
they can pace themselves and plan their questions. (Be sure to 
announce at the onset of your talk how you prefer to handle any 
questions from the audience: do you want them to hold questions 
till the end? or raise a hand and ask during the presentation?) 

If your talk is heavily sprinkled with acronyms, you may wish 
to prepare a poster or a flipchart with translations of the 
acronyms. If you need to refer frequently to a complex diagram, 
consider distributing handouts of the diagram. 

Speaking pitfalls are everywhere — but practice can make you 
almost perfect. Try to weed out the colloquial pause-fillers of 
"urn" and "uh 11 and, although you don't need to be formal , do try to 
employ good English. As always, attempt to use gender neutral 
language in your speech. Finally: remember that humor is great if 
it works for you — but don't try to "entertain" if that's not your 
style. 

There is a large body of literature on the market which 
focuses specifically on public speaking and the preparation of 
audiovisual supports for speeches. Take advantage of these 
publications, and learn from other people's mistakes so they won't 
become your own. 
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Going to the Conference 



Any last minute thoughts? This warning may sound unnecessary, 
but it is based on a wealth of observed experience: if you're 
relying on slides, overheads, handouts, whatever — be sure you 
know which member of your party is responsible for bringing each 
item. If you 1 re flying to the conference site, carry your 
materials — including any speech cue-cards — onboard with you: 
lost luggage, like most inconveniences, always occurs at the worst 
possible time. 

Consider other conference attendees as possible resources 
during your presentation. Is there someone from your campus 
familiar with the project, or someone from another institution 
knowledgeable in the field? You may want to solicit their support 
(at least, their physical presence) at your presentation; during 
question and answer time, these resource people may be able to add 
additional information that will enhance your audience^ learning 
experience. 

At the conference, what can YOU do to maximize your chances of 
success? First and foremost: take advantage of all the possible 
assistance provided by the local committee staff, CUMREC really 
wants your presentation to go well. To that end, at every 
conference they provide: 

a practice room , similar in size and shape to 
the actual presentation rooms and containing 
similar equipment, open extended hours during 
the conference (you can sign up for time in 
the practice room at the conference 
registration desk) ; 

a reception for speakers and moderators f at 
which you can meet the moderator assigned to 
your session (the moderator identifies the 
session number to be written on the evaluation 
form, reminds the audience to complete an 
evaluation, introduces the speaker {s} and 
generally sees to it that the session begins 
and ends on time) ; 



ERLC 



9 q 

<•* o 



— 245 — 



a room monitor , assigned to your specific 
presentation (the monitor ensures that 
equipment is working and will locate 
assistance in the event of room/ equipment 
problems) ; 

a staffed registration desk , your first place 
to turn if you have a question or a problem. 

What else can you do to enhance your presentation outcome? If 
yours is not the first session on the conference schedule, you can 
pick up some helpful hints by observing other speakers 1 
presentations. Ask yourself what you especially liked in a talk — 
and what you liked less. Be at your assigned room early! Make 
contact with your moderator and room monitor, verify that equipment 
is positioned correctly, that handouts are located conveniently by 
the door, and that the room monitor knows which light switches you 
want adjusted during the talk. Most of all: be excited about your 
subject . . . and enjoy yourself! If you feel relaxed and 
comfortable, you will put your audience at ease — and they will 
enjoy the program more. 

Try not to be nervous 1 Fear of presenting is one of the 
biggest obstacles to making the initial commitment to present, as 
well as to following through with it. "Think of your speech as a 
big staff meeting. Particularly at CUMREC, the people are really 
interested in what others' experiences have been — CUMREC gives 
you the opportunity to talk to your colleagues about these 
experiences , and learn from theirs." (Maria Thomas, University of 
Kentucky-Lou i s v i 1 1 e ) 

A word of caution on what to expect from your audience: 
remember that an audience is not static — with all good 
intentions, attendees may enter a program late and leave the 
program early. Don't take it as a personal affront; just keep 
going ! 

It's finally over — now what? Celebrate! You really did it! 
You can be proud of yourself, and be assured that CUMREC, too, 
appreciates all the hard work you've done. Do remember, in the 
midst of the flush of success, to thank the people who helped you 
prepare your paper and presentation. Drop a note to your boss, who 
provided you with the institutional (and financial) support to 



attend this conference. Send a thank-you postcard from the 
conference site or bring back a treat jEor your fellow workers and 



you were busy with your CUMREC responsibilities) . The winners of 
the CUMREC '92 best paper award took the time to telephone the 
creator of a particularly effective videotape, apprising her of the 
award and thanking her again for her efforts (Jack Duwe and Tom 
Scott, University of Wisconsin-Madison). These gestures go a long 
way toward making others feel good — and may help facilitate any 
future CUMREC presentation endeavors. 

Other things to remember, when you return to your home campus: 
Share the results of the presentation; give feedback on the 
conference to relevant offices and staff. And don't forget to 
update your resume to indicate that you were one of the selected 
conference presenters this year! 



Best Paper Award 

The evaluations handed in by your audience at the conference 
presentation (see Appendix B) , combined with the original score 
assigned your written paper by the Program Committee, make up your 
overall score. Note that, in the oral presentation, evaluation 
scores are totalled and divided by the number of evaluations, so 
that the less heavily attended presentations are not disadvantaged. 
It is the committee's goal to announce the winner of the best paper 
award, as well the other top papers of the conference, at the 
closing plenary session on Wednesday morning. The names of the top 
papers, their authors, and the authors' institutions are announced 
in the first CUMREC Newsletter after the conference, in late June 
or early July. 
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Conclusion: Why We Do This 



We have already pointed out some of the benefits to be accrued 
by participating in the writing and presentation process. Obvious 
benefits are derived, certainly, by the authors/presenters 
themselves. When asked what was the best part of presenting a 
CUMREC paper, former presenters responded enthusiastically: 
"Making contacts with people who are doing the same thing you are, 
or who are moving in that direction. Most are willing to share how 
they did i t and the exchange of ideas improves both . The ones 
moving in that direction have followed up with questions and 
thoughts which triggered 'light bulbs' in my head to make changes 
that have improved my system." (Lee Anne Hoppe, Virginia Tech) 

Benefits derive to the authors • /presenters 1 institutions: "We 
are constantly asked to send information about our project to 
interested parties at other institutions in Wisconsin and 
throughout the country. One of the major benefits of writing the 
CUMREC paper has been that we now have the right kind of document 
to send in response to such requests. If we had not written the 
paper for CUMREC, we would still be responding to these requests 
with bits and pieces of separate related documents that may or may 
not fit together very well." (Larry Rubin, University of 
Wisconsin-Madison) 

Benefits also derive to the conference attendees, who are able 
to select from a broad array of presentation topics to enhance 
their own knowledge and experience. And, ultimately, it is the 
CUMREC organization itself that benefits. The conference owes not 
only its success, but its very survival, to the presenters and 
participants who gather together each year to share their 
experiences and help each other strive for ongoing success in 
higher education computing. 



Appendix A 
CALL FOR PAPERS 



1992 — Discover Neiv Worlds With Technology 

INTENT TO PRESENT: I plan to submit a paper to be considered for pre- 
sentation and publication at CUMREC '92 on the following general topic: 
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PLEASE PRIST 
Name _____ 



Title 



Institution 



Street or PO Box 



Zip ( ode tVtrtil (.ixict 



UMephonc ( 



Authors Release, Warranty and Understanding 

If this paper is selected for presentation ax CUMREC '92. l/wc grant and assign 
CUMRIiC '92 the right to publish the resulting pajief prepared for ihc PnKccdings 
of the Conference 

l/wc gu -ranter that l/wc are the sole proprietors) of the work and l/wc have full 
power ui make this agreement, that the work doc* not infringe on the copyright 
or other proprietary right of any other person, and that the work contain* no 
libelous or other unlawful matter and makes no improper invasion on the privacy 
of any other person 

l/wc understand that those who present papers it tH!MRE<" <>2 must register for 
the Conference and pav the Conference fee. l/wc also understand thai l/wc will 
not be paid am honorarium or fee for the presentation or us prcpjraiion. nor 
will I /we be reimbursed for travel or any other expense* incurred 

Authorts) Signature's) 



Date 



INTENT DEADLINE: September 30, .991 

SEND INTENTS TO: CUMREC '92, Debbie Stcdman, P.O. Box 161824, Miami, FL 33110 



ERLC 



SI W1 AVAILABLE 



— 249- 



Appendix B 
PRESENTATION EVALUATION 




CUMREC Paper Presentation Feedback 

Session Number: 



rj iiTjjDjZf To assist the CUMREC Program Committee with the selection of the Best Paper 
njiTtiCtiTii Award, please rate the quality of the paper presentation from 1 to 10, with 10 
DC nu ti ii being the highest score and 1 being the lowest. When rating the paper, consider 

mmm^— mmmmm such criteria as organization, completeness, clarity of communication, integration 
of graphics (if applicable), and technical accuracy. 

(Please circle) 

RATING 123456789 10 

(Lowest) (Highest) 
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Education and Training (E&T) for Information System 
(IS) users is an on-going and non-ending process. Every 
Management Information Sy~'\ems (MIS) provider is faced with 
an initial E&T effort during system implementation. After 
implementation, employees come and go, resulting in a user 
base with constant turnover. Each time an employee leaves 
the institution, someone feels the impact from the loss of 
an "expert" user of the IS. Likewise, when a new employee 
comes aboerd, someone is faced with the task of educating 
and training the new user. 

This paper will describe the information which IS users 
need, and then present a guideline for developing E&T pro- 
grams. Since several acronyms (such as E&T, IS, and MIS) 
will be used in this paper, a list of acronyms is provided 
on the last page. 

WHEN ARE EDUCATION AND TRAINING NECESSARY? 

How many times has someone hung up the phone in disgust 
and said, "Those dumb users — they don't know what they are 
doing!" Many times uninformed users are major frustra- 
tions — someone is trying to use the system and does not 
know what he/she is doing. 

Maybe someone calls to say the data is not right, or 
the program is not working correctly. But examination and 
testing reveal that "the information is right!" and "the 
program does work correctly!" Further discuss on with the 
user discloses a user who does not understand either the 
industry (see "PDI" below) which originated the IS applica- 
tion, or the procedures which drive the IS, or how to inter- 
pret the data being reviewed! 

Interruptions — think of how much could be accom- 
plished if there were less interruptions! Interruptions 
take time, which presents an additional, and very obvious 
consideration: Not only do interruptions indicate a need for 
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training, but they also indicate a very real cost — labor 
is less productive than desired. Both you and the end user 
will increase productivity if inquiries and interruptions 
are be reduced or eliminated. 

These few examples show the potential success from 
E&T — a reduction in problems and distractions (and result- 
ing labor costs!!) may be realized by several differ ent 
depa rtments , which means there will be multiple benefactors 
from a successful E&T program. 

WHO ARE THE PRIMARY BENEFACTORS OF E&T? 

The rewards received from a good E&T effort will be 
realized by three different and distinct benefactors: 

The HIS Department xs the provider of data processing 
services such as application programming and computer opera- 
tions . 

The Proprietary Department of Information (PDI), which 
is the primary user and processor of the data, is the infor- 
mation authority, possibly being responsible for compliance 
with governmental regulations. PDI can refer to departments 
such as Human Resources (sometimes referred to as Person- 
nel) , Accounting, Budget, Student Records, etc. 

For the purposes of this paper, M end users" will refer 
to the users of the IS who are beyond the PDI. These de- 
partments have inquiry or data entry uses of the IS, but not 
as the primary (ie., PDI) user of the IS. 

Before proceeding, it must be mentioned that end users 
view E&T as another service from MIS and/or PDI. If MIS 
and/or PDI are not user-friendly, and their services do not 
meet the needs of the users, then the E&T effort will be 
poorly received and less successful. Furthermore, success- 
ful E&T is partially a result of educating the users in the 
language and relationships of MIS and/or PDI. When rela- ( 
tionships between the associated departments are competitive 
or combative instead of cordial and user-friendly, there are 
questions which cannot be answered to the end users. A 
certain amount of confusion and uncertainty will remain and 
the proficiency of the end users will not fully achieve 
expected results. For these reasons, E&T will achieve 
greater success when it is supported by service-oriented MIS 
and/or PDI. 

Now that you have read to this point, it is only fair 
to say that this paper focuses on the E&T of the end users. 
If your IS does not have end users other than PDI, you will 
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find that the MIS and PDI were involved during IS definition 
and testing, and should be familiar with the system at the 
time of implementation. 

WHAT REWARDS AND BENEFITS CAN E&T OFFER? 

Because several IS benefactors exist, thu. rewards and 
benefits of E&T can be multiple and simultaneous. 

First, when E&T are provided to coincide with implemen- 
tation, dual short-term benefits occur. End users become 
functional and proficient in their departments within a 
shorter time, while IS implementers (both MIS and PDI) 
return to their normal jobs sooner. 

Second, when E&T is provided on an on-going basis, 
multiple benefits occur. As new users become functional and 
proficient for their departments within a shorter time, IS 
support personnel (both MIS and PDI) experience labor and 
productivity gains from the absence of problems and inter- 
ruptions. 

Even when formal E&T programs are not in place, the 
startling fact of life is that E&T is occurring on an ad- 
hoc, informal basis. This ad-hoc, informal E&T is not only 
inefficient, it increases labor costs as new users learn 
from two primary sources: from help-calls to the PDI and 
MIS, or word-of -mouth from someone down the hall. Learning 
from either help-calls or word-of-mouth suffers from the 
same maladies: Questions are interruptions occurring at 
inopportune times which may not receive appropriate time and 
attention, and are often answered by someone who provides 
incomplete or incorrect assistance. 

Two negative reactions result from this ad-hoc, infor- 
mal E&T. First, the MIS, PDI, and down-the-hall support 
departments are experiencing unwanted and unnecessary labor 
and productivity losses. They typically respond in a manner 
to "fix" the situation, and rarely take the time to discern 
and explain information gaps that come from misunderstand- 
ings or lack of knowledge about the underlying concepts and 
terminology of the MIS, the PDI, or the application. 

Second, users are becoming proficient in bits and 
pieces, relegated to positions of learning by failing, of 
learning without receiving important background information, 
and of never learning the "why's" of their situation. They 
never receive the benefits from a "large picture" system 
overview, from discussions of integrated components, and 
from the application of the IS to the their "real world." 
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In summary, the benefits from a successful E&T program 
will be seen in increased productivity of all concerned 
MIS, PDI, end users, and down-the-hall helpers. However, 
for E&T to be the most beneficial, it is important to under- 
stand the definitions of and differences between "education" 
and "training* 11 

WHAT ARE "EDUCATION" AND "TRAINING?" 

Surprisingly enough, there is a large difference be- 
tween "education" and "training" as used in this paper. 
Education refers to presenting information that will provide 
an understanding of the IS and any terminology which is 
used . The primary effort is directed at describing the 
concepts and terminology (C/T) which form the underlying 
foundation of the IS system. Learning that users must 
obtain "user identifications" and use "passwords" to "Logon" 
and "Logoff" are C/T from the computer industry. 

To be most effective, education should recognize that 
the MIS and the PDI represent two different industries with 
separate C/T (MIS is an industry, Personnel is an industry, 
Finance and Accounting are industries, higher education is 
an industry, etc.) The purpose of education is to present 
the appropriate information about all the industries in- 
volved so that users can understand the IS system and inter- 
pret the terms they will see on reports and inquiry screens. 

Training refers to developing users ' skills so they can 
do their work . Learning how to log on and off the IS system 
is a skill. Other skills include using the commands to 
perform inquiry and data entry procedures, preparing input 
documents, reading and reconciling reports, etc. 

To be most effective, "training" must rely on the 
foundations of the C/T presented during "education," but the 
purpose of "training" focuses on how to use the system. It 
should be closely aligned with the daily activities of the 
users so that they are prepared to go to work upon complet- 
ing class. 

"Education" and "Training" often occur hand-in-hand 
where there is little distinction between the two as sepa- 
rate formal activities. The need for both "education" and 
"training" can be illustrated by two typical situations: 
- A trainer may jump directly to "training" activities to 
show how to use the system, and overlook the importance 
of C/T education. As a result, the users will continue 
to struggle in the class room, and will leave talking 
about how hard or difficult the system is to learn and 
use . 



A trainer may unconsciously view "education"-style 
presentations as adequate, saying, "I told them how to 
do it. 11 However, user help-calls indicate the users 
still do not know how to "do" the basic operations once 
they return to their jobs, because they did not receive 
skills training. 

Questions from the users during presentations or class 
activities will often indicate the need to review C/T. 
"Dumb" questions may indicate a lack of understanding of 
basic C/T and the trainer may need to explore the user's 
question to determine if the missing knowledge is related to 
the MIS , the PDI, or the IS application. 

In summary, education and training are two integrated 
parts of one process, and both must be included to provide 
the greatest benefit to the institution. It is important to 
recognize that 

"education" is used to prepare someone's understanding 
before "training" can provide skill development . 
"education" -type presentations alone may not provide 
the skill development for someone to become a good user 
of the system. 

n training" -type presentations alone may not be compre- 
hended by the users and may not bring anticipated 
resul ts . 

WHERE DO YOU START TO DESIGN AN E&T PROGRAM? 

The design of an E&T program begins with an examinaticn 
of the users of the IS- In the language of the training 
industry, this is referred to as "Audience Analysis." Two 
questions should be c*sked initially: 

"What groups of people can be identified as users?" 

"What do the user groups want or need from the IS?" 

These "wants and needs" of the user groups are very 
important. The users are interested in what the IS will do 
for them. They want to know if the IS will solve their 
problems or prevent errors. Therefore, for an E&T program 
to be successful, it must show the users which features will 
help them be more productive. 

These two questions will, first, define the depth and 
breadth of the E&T which is required, and second, indicate 
how to structure and package E&T for delivery to specific 
user needs . However, the answers to the two questions 
should be further examined by asking a third question: 

"What C/T do the user groups need to understand in 

order to interpret the information they want and need 

from the system?" 
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This third question is an important key to providing 
successful E&T because the answers indicate what education 
to provide the users so they can understand the IS. 

The final design consideration is the language of 
communication . Knowing what to present is only par t of the 
problem — knowing how to express the informati on is equally 
important I E&T must be provided from the perspective of the 
user, and not from the perspectives of MIS or PDI. Users 
will comprehend E&T with greater success when it is ex- 
pressed in their language — when C/T are defined and illus- 
trated in the words of their daily vocabulary. Here are two 
examples of poorly expressed E&T : 

- A highly qualified presenter from MIS provides E&T with 
too much information about data bases, files and file 
names, computer and data processing information, and 
expresses it in language laced with C/T from the com- 
puter industry. The result is that the users sit 
through information they do not understand and will not 
use, attempting to glean the information they want and 
need. 

- A highly qualified presenter from PDI provides E&T with 
information on how to use the IS without explaining 
background C/T and expresses it in the language of the 
PDI. The results are that the users may not retain 
important topics because they do not understand the 
language, and then they try to use the system without 
knowing why they are following certain procedures. 

Before leaving this topic, it is important to note that 
E&T for the implementation of a "new" IS may be able to 
build upon the present knowledge of the current users in 
order to fill the gaps between the old and new system. This 
is an instance when abbreviated E&T can bring successful 
results . 

In summary, successful E&T is built upon a foundation 

(1) providing the information and skills 

(2) the users want and need 

(3) in the language of the users. 

WHAT ARE SOME TYPICAL USER GROUPS? 

While every IS will have variations of the user groups 
involved, the following is a list of possibilities for a 
large system accessed by every department, such as the 
personnel or budgetary IS. 

Executive Management. The President, Vice Presidents, 
Deans, etc., will require very little E&T. A summary pre- 
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sentation will probably be sufficient (their concerns are 
usually institution-wide and they receive summary informa- 
tion prepared by their administrators) . The greatest oppor- 
tunity for E&T is during initial IS implementation, when 
their primary interest is in time line progress and expected 
benefits. 

Management E&T. Department Heads — Chairpersons, 
Directors, Managers will be interested in an overview of 
the information that is available to them and in the C/T 
they need to effectively communicate with their staffs. 
Depending on their personal management style, they may be 
interested either in where to find budget balances or cur- 
rent employee information on reports or inquiry screens, but 
they are rarely interested in detail reports, transaction 
lists, and source documents, or in the details of the pro- 
cesses and procedures that are followed. 

End Users. This group will be further categorized 
according to their uses of the IS. Are data entry and 
inquiry centralized? Or is data entry selectively decen- 
tralized and with inquiry available to anyone? User groups 
might fall into some of these categories: 

Source document preparation of budgeting, purchasing, 
and personnel forms which will be data entered in the 
IS. Users will need detail "education" in the C/T of 
the MIS, the PDI, and the documents they are preparing, 

- Restricted data entry, where only certain data entry 
processes are decentralized. Users will need detail 
"education 11 in the C/T of the MIS, the PDI, and the 
processes they are entering. Then they will need 
"training" in the relevant entry hardware features, 
hardware operations, data entry procedures, and balanc- 
ing and verifying procedures for the processes they are 
entering. 

- Restricted inquiry, where only certain inquiry screens 
are available to the users. Users v'ill need detail 
"education" in the C/T of the MIS, tie PDI, and the 
screens they will access. Then they will need "train- 
ing" in the relevant hardware features, hardware opera- 
tions, inquiry commands and procedures, and how to 
cross reference their source documents to their inquiry 
screens . 

- Unrestricted data entry and/or inquiry. Groups such as 
these will need expanded versions of E&T as described 
for the selective groups. 

Proprietary Department. E&T for this group will be 
largely determined by the development and implementation 
plan followed by MIS (they might receive some MIS or vendor- 
supplied "education" in the beginning to facilitate their 



involvement) . When PDI participates in the plan, they will 
learn "on the job. 11 If PDI is not involved with MIS in the 
plan, they should be viewed as the end users described 
above . 

On-going E&T for PDI's employee turnover will probably 
be best provided by PDI, due to the highly technical nature 
of the information. However, attendance at end-user E&T for 
data entry or inquiry is highly effective for giving the 
broad overview and background on which the technical in- 
department E&T is based. 

IS Department, Like the PDI, MIS will pursue E&T in- 
department, or from the supplying vendor. Once again, 
however, on-going E&T for employee turnover can be facili- 
tated by attending end-user data entry and inquiry E&T to 
build a foundation for the more technical MIS E&T. 

In summary, identifying the user groups is a step 
toward determining the E&T which must be provided. 

WHAT DO USERS WANT AND NEED? 

Research of end user wants and needs revolves around 
the question, "What do you want to do? 11 , or if asked of the 
PDI, M What do you want the users to do? 11 This refers to the 
results that the end users want or need to accomplish. 

End users may reply, "I want to look up my budget 
balances, 11 or "I want to see if an employee was paid cor- 
rectly « " 

PDIs might reply, "I want end users to see if a check 
was issued to the vendor instead of calling me, 11 or "I want 
end users to enter their own time cards ♦ " 

These replies from the end users and PDI can be used to 
build the following list of training topics: 

(1) Budget balances inquiry. 

(2) Employee time card entry and payment inquiry. 

(3) Vendor payment inquiry. 

Notice item (2) . Questioning both benefactors has 
turned up related topics which may be packaged together for 
E&T purposes. 

The questions and answers presented above are expressed 
in "training 11 language — how to "do" things. Next, it is 
important that the research goes a step further to determine 
what C/T "education" the users should have in order to 
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achieve the desired results. Following might be "education" 
examples for the topics listed above: 

(1) Budget balances may include eeveral types of totals and 
involve one or more procedures. For instance, budget 
balances may include revisions to the budget, encum- 
brances, expenditures, etc. which need to be defined as 
part of showing a user which inquiry screens list 
budget balances. Additionally, the procedure of encum- 
bering and expending funds may need to be explained so 
that the user can interpret the information on the 
screen , 

(2) Before time card entry and employee payment can be 
presented, it may be necessary to discuss time periods, 
cut offs, and processing and payment dates. 

(3) Looking at a screen indicating vendor payment will be 
more meaningful if the user understands invoice and 
payment processing procedures. 

In summary, E&T for inquiry and data entry must neces- 
sarily go beyond how to access or enter the information to 
include the C/T inherent in the IS. 

HOW ARE E&T COURSES DEVELOPED? 

From the above list of topics, we can begin the process 
of developing our E&T programs. We will follow a simple 
procedure of sequencing the material, defining learning 
objectives, and designing participant activities, 

(If you are having trouble understanding this last 
sentence, it may be because I have not previously 
discussed training industry C/T such as "sequenc- 
ing the material," "learning objectives," or "de- 
signing participant activities" — and now you 
know how difficult it may be for an end user to 
understand someone from MIS or PDI!) 

Sequencing the Material 

The first step is to determine the sequence for pre- 
senting the topics. Asking two questions will assist in 
"sequencing" the material: 

- "What does the user need to know first?" This question 
will assist you in determining the order of your top- 
ics. In the second topic listed previously, you may 
determine that a user should learn how to inquire for 
payroll information as a prerequisite to the topic of 
entering data, ie. , it may be easier to teach data 
entry if the user knows what the targeted end result 
should be! 



-261 - 



238 



"What dees the user need to know in order to learn this 
topic?" Now you are asking what background education 
is necessary so that the user will comprehend the 
topics to be presented. Again looking at the second 
topic above, you may determine that the user must 
understand and be able to do certain math computations 
as a prerequisite to learning about payroll entry and 
inquiry. 

Using the answers to these questions, here is a "se- 
quenced" topic list for time card entry and payment inquiry: 

a. The C/T regarding payroll time periods and cut-off, 
processing, and payment dates. 

b. Formulas and computations used in computing pay. 

c. Inquiry commands and screens for viewing employee 
payments . 

d. Data entry processes for entering time cards. 

These are very broad topics which might be further 
divided into sub-topics. For example, the last topic about 
data entry will include sub-topics about error messages and 
error recovery during entry. 

Defining Learning Objectives 

Now that we have our "sequenced" topic list, we will 
re-state each topic (and sub-topic) as a learning objective, 
which accomplishes two important steps in our training 
development : 

Objectives focus the effort of the trainers toward 
accomplishing certain goals. Remember, the overall 
goal of training is to reduce errors and increase 
productivity. The objectives will become the steps we 
will follow in pursuit of that overall goal. 
Objectives must be stated from the perspective of the 
users, which helps the trainer think in the language of 
the users. It is the users who must be able to "do" 
certain things, and only if the users "do" those things 
when they return to the job can we say our training has 
been successful. Expressing from the perspective of 
the users also serves to change our focus from "telling 
what we know" to "giving the users what they want and 
need . " 

Here is a simple "User-action-task" guideline for 
writing your learning objectives: 

User. Start your objective with "You will be able to 
. ..". This causes you to focus on the perspective of 
the end users and what they must "do." 
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- Action. Follow the intro with an active and measurable 
verb that represents what the users will be able to 
"do 11 after receiving training. This means you must 
imagine what the users can "do" that will indicate what 
they have learned. 

The most common pitfall is to use verbs that may seem 
active, but are not measurable. This occurs most 
frequently when you are defining objectives for C/T. 
The sub-topic of error routines for data entry is a 
good example. You want to teach the error codes and 
their respective meanings. The tendency is to write 
your objective as "You will be able to (understand, 
learn, remember, etc.) ..." However, these verbs are 
not measurable. How can you measure "understanding?" 
Instead, you should use verbs such as "You will be able 
to (describe, recite, list and define, etc) ..." 
Active, measurable verbs set the criteria for observing 
and determining if the users have learned the desired 
topic . 

Task. Complete your objective with the task to be 
learned, which the users should to be able to do when 
they return to their jobs. 

The following might be the list of learning objectives 
for the topics we have discussed previously: 

You will be able to: 

List and define the cycles of recording time and 

paying employees. 
Describe the various formulas and computations 

used to compute pay. 
Select and view employee payroll information 

stored in the computer. 
Enter and reconcile time card information for 

employee payrolls. 

Looking as these examples, you will note that the 
objectives have been worded in language that the user will 
understand. The importance of this is described in the 
following section . 

WHY SHOULD LEARNING OBJECTIVES BE WRITTEN IN USER LANGUAGE? 

From the standpoint of the trainers, we have already 
discussed the importance of thinking and expressing from the 
users' perspective. In addition, the E&T program benefits 
from properly stated objectives in three related efforts. 
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1 EST Brochures. Most users ask, "What will I get out of 
this training? 11 The learning objectives answer that 
question. They are "publicity 11 or "marketing 11 verbiage 
that express the benefits of attending E&T, These 
learning objectives can be used to create training 
brochures , conf irmation letters , posters , etc . 

2 Class Evaluations. As class is completed, you will 
want to have an evaluation to get the users' feedback. 
The learning objectives can be used as two sources of 
feedback: 

* To find out how the users rate themselves. Simply 
restate the "user" beginning of the objective to, 
"I am able to ... ," and ask the users to rate 
themselves on a scale. 

* To find out weak points in the training program. 
After the users have rated themselves, the trainer 
can review the evaluations to see which learning 
objectives were rated lower by the users and 
therefore need more time or emphasis during class. 

3 Certification. If you want to have employees "certi- 
fied" as to their competence in the IS, your learning 
objectives will form the basis of your testing program. 

In summary, learning objectives, when they are properly 
stated, can be used as a consistent thread through the 
training program, from the first publicity a user sees, ^ 
through the training program, to the evaluation or certifi- 
cation testing at the end. 

IS THERE A WAY TO MAKE LEARNING EASY FOR THE USERS? 

The easiest method for the trainer is not necessarily 
the best method for the learner. For example, a lecture 
might be easy to prepare and adequately cover the training 
topics but might not provide adequate learning opportunities 
for the users. E&T will provide better learning opportuni- 
ties when consideration is given to how adults learn . 

The adult education industry has accumulated research 
about how adults learn best, and the simplest statement is 
to say that adults prefer to be participants instead of 
recipients of E&T. This means that adults prefer education 
that allows them to experience and test their experiences — 
"activity based" E&T. You should keep the following in mind 
when developing E&T for adults: 

- Adults are result oriented, and expect information to 
show them how to "fix" things or remove barriers. They 
expect what they learn to be immediately useful, will 
apply new information to present circumstances, and 
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will place greater value on the things that will pro- 
duce results on the job, 

- Adults want to participate in the process. They rely 
heavily on their past experiences and beliefs. They 
will measure new information against what they already 
know and want to test new information for validity. 

- Adults function best where they can draw on their 
experience , act as a resource to the trainer and oth- 
ers, collaborate as a group, and share in planning or 
decision-making. 

- Adults will remember more information for a longer 
period of time if they have an opportunity to use the 
information successfully in class before returning to 
the job. 

To provide E&T that is most effective for adults, you 
should plan activities for your learning objectives. The 
activities should allow the users to process the new infor- 
mation or cause the users to make decisions based on what 
they have learned. Looking at our list of learning objec- 
tives, you might design activities as follows: 

- A discussion about the C/T related to pay periods can 
be followed by a matching terms exercise, a story that 
requires the users to establish pay periods, or 
true/false exercise that tests the users' comprehension 
about various aspects of the information. 

- A discussion of computations and formulas can be fol- 
lowed by math exercises that test users' understanding 
of the material. 

A review of on-line screens can be followed by guided 
exercises where users review their own departmental 
employees for certain information. 

- Data entry reviews can be followed by exercises where 
users enter sample data* 

In summary, activities are the best form of E&T for 
adults. Activities are most effective when presented as 
exercises instead of tests, when users are allowed to work 
together, and when answers are reviewed in open discussion. 
Activities can provide settings where adults have the oppor- 
tunity to relate the material to their present on-the-job 
work. 

HOW DO I CHOOSE SOMEON E TO PREPARE THE E&T PROGR AM? 

Choosing the person who will lead your E&T effort is a 
very critical factor in the overall success of your E&T 
program, as shown by the following: 

- As we have seen, this person should be able to under- 
stand and communicate the important C/T's of the MIS, 
the PDI, and the application. 
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You way be able to select an individual from either the 
PDI or the MIS, but the chosen specialist should be 
able to communicate in the language of the users . 
If you want the users to perform is functions ("do" the 
work) , beyond just "knowing 11 critical information about 
the IS, then you want to view E&T as a learning experi- 
ence for the users. This calls for activities which 
allow skill development for the users, and allow the 
trainer to observe, measure, and evaluate the users' 
new abilities. 

One danger in selecting an E&T specialist is to assume 
that the obvious choice is a "technical expert" from PDI or 
MIS. Here are some possible pitfalls: 

Trainers are often appointed from the MIS or PDI as the 
most knowledgeable spokesperson (technical expert) 
without a background and understanding of education 
and/or adult learning theories; 

"Technical expert" trainers may unconsciously use C/T 
which is everyday language in their home department 
(MIS or PDI) but is unfamiliar to the users. Two 
results may accompany this occurrence: 

* Users may not understand the presentation, and 
after the class will talk about how hard or diffi- 
cult the system is to learn, 

* Users will often evaluate their trainers in glow- 
ing reports as an expert with an excellent back- 
ground, and refer to the class as a great experi- 
ence, and at the same time return to their depart- 
ments and struggle with the most basic operations. 

It must be noted that evaluations prepared by users who 
do not understand the material can be misleading. 
Users who do not understand the trainer or the material 
will often give excessively high ratings to the class 
and trainer when compared to users who have a level of 
proficiency and understand the trainer and the materi- 
al. This is another reason for objectives to be active 
and measurable, and E&T to be activity based — the 
trainer must be able to observe the participants to see 
that the material is comprehended. 

For these reasons, it is advisable to consider that 
"technical expert" trainers, while recognized for their 
proficiency, may not communicate in the language of the 
users, and they may receive misleading class evaluations 
while not achieving expected results. 

In summary, you want to choose someone who is a good 
communicator, who understands the C/T's involved, and who 
offers E&T to meet the needs of the users. 
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SUMMARY 



Providing education and training for information sys- 
tems is more than dispensing information and reviewing 
system features. The information must include the concepts 
and terminologies from both computer and information indus- 
tries so that the users can understand the information 
system. The reviews of system features must allow the users 
to practice and demonstrate their competency prior to leav- 
ing the class. 

For education and training to be successful, the 
achievements of the program and the participants should be 
measurable by the trainer. By designing and developing 
adult-targeted activities with learning objectives, educa- 
tion and training become measurable, and comprehension is 
observable by the trainer! 

The success of education and training will be evidenced 
by users who become self-sufficient, and by information 
system providers who are less distracted by interruptions 
and problems. 

In the final analysis, many departments will benefit 
from education and training programs that assist the employ- 
ees (and the institution) increase personal and corporate 
productivity. 



LIST OP ACRONYMS 

E&T Education and Training 

C/T Concepts and Terminology 

IS Information System(s) 

MIS Management Information System Department 

PDI Department of Proprietary Information 
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Islands of Automation and How They've Been Formed. 

Since the 1960's, when computers began to be used for administrative tasks, sys- 
tems development has been focused on individual functions usually performed by one 
organizational unit. In the finance area, processes dealing with the Financial Accounting 
were "automated" followed soon by Accounts Payable and Receivable. In the Human 
Resources area, attention was paid to the payroll function while the foci of automation 
efforts in Student Records were admissions and registration. 

We refer to these systems, sets of computer programs designed and implemented 
to process the data specific to a functional activity (e.g. Admissions), as islands of auto- 
mation. To extend the metaphor, we may even think of the all the systems used in an 
organizational unit as a "system archipelago". 

In the 197(Vs systems designers, realizing that the output of one system was fre- 
quently used in another, attempted to make them work more closely by "automating" the 
interactions. One system created transactions that were "fed" into another, more or less 
automatically. Thus, with the construction of bridges (or causeways, in some cases), be- 
gan the age of the "Integrated Application System". 

An example of this is an "integrated" Financial Records System. At the risk of 
over-simplifying, the Purchasing subsystem sends invoice transactions to the Accounts 
Payable subsystem which in turn sends transactions to liquidate encumbrances in Finan- 
cial Accounting. Rather than integrated, it is more appropriate to refer to these as inter- 
faced application systems since there is merely an automation of the interaction between 
existing systems. They have merely been re-packaged, not re-engineered. 

When the Age of Data Administration arrived in the 1980's, it became apparent 
that these so-called "integrated systems" were misnamed. Data Administration implies 
managing information as an enterprise [read; institutional] resource, not as a functional 
resource. This can be illustrated with the attributes Name and Address. The Library 
maintains the Name and Address of individuals librarians know as Patron while the 



Registrar maintains Names and Addresses of individuals they call Instructor or Student. 
The Controller maintains the Names and Addresses of Account Administrator, Traveller 
and Vendor. The Personnel/Payroll Office does the same for Employee and the Develop- 
ment Office for Alumnus. However, a person whose job it is to administer data under- 
stands that Patron, Instructor, Student, Employee, Traveller, Vendor, and Alumnus are 
the same thing: a Person and whether a Person borrows books, instructs, studies, works, 
travels, administers accounts or attended the institution are merely characteristics of that 
Person. This implies that data about the same things are used by many organizational 
units and applications that support those units' activities. 

Unfortunately, systems thinking was not able to deal with this "cross- 
functionality" since it perceived data only in the context of the function being per- 
formed. To the Library System, Patron name and address is different from that of the 
Instructor or Student. In other words, the Library manages the names and addresses for 
the same entities as the Personnel Office, the Registrar's Office, the Controller's Office 
and the Development Office (not to mention others). 

Thus, it became apparent that systems thinking had not produced a data resource 
that was usable by all of the institution's functions that needed to use it. Systems think- 
ing had produced a data resource that was dis-integrated. The same data was being re- 
corded and maintained by many islands in each of the institution's many systems archi- 
pelagos. 

The Goals of the New Administrative Applications. 

The realization of this came as quite a shock to us in Administrative Applications 
— the computer systems people, since it was clear that we were mostly responsible for it: 
for twenty or so years we had been the greatest proponents of "systems". We had led the 
University in an orgy of systems development and implementation during the early and 
mid-eighties, replacing the library, development, financial, human resources, student re- 
cords and a host of smaller systems. Most of these new systems were packages and we 
had been required to tailor them to some degree. 

In addition, the twelve programmers, programmer/analysts and systems analysts 
had become system experts, e.g. specialists in finance, human resources or student re- 
cords. They received much of their fulfilment by doing good things for their "users" and 
in response, their "users" expected to deal with certain people whose purpose was to 
maintain and enhance their systems exclusively. At times it seemed that functional man- 
agers saw our employees as their programmers, that is, extensions of their department. 
Furthermore, departments that had programmers "allocated" to them for some time, ex- 
pected that their software v/ould be modified more or less automatically while other or- 
ganizational units went without attention. 

It was clear that we were part of the problem. It was also clear that the status quo 
had to change and that our group should be prepared to lead this change. Our goal, then, 
was to give the University a tool to use in its re-engineering efforts: a group of informa- 
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lion scientists and engineers that could be deployed to create information services for the 
institution as opposed to operational systems or one functional activity. 

To do this we needed to completely change our approach to our business. This 
new cadre of information scientists and engineers, which we now call informaticians, 
had to be liberated from the functional silos which they occupied. The obvious answer 
was to change the infrastructure (the only option management had), that is, reorganize. 
We also had to re-orient or change our relationship with our external environment. And, 
of course, we had to re-equip both in terms of hardware and skills. 

The New Organization. 

Nobody in our group had experienced all urree of these changes happening at 
once. Some of us had moved from organization to organization. During our careers all 
but our most junior colleagues had changed from supporting one function to another 
and, of course, we all had adapted to new hardware and software technology. But chang- 
ing all three at the same time was the same as turning the organization upside down and 
shaking it. 



Manager 



Overall Management 











| Application Resource Management 


Data Resource Management 



Maintenance and enhancement of 
software for its operational life. 
Quality Assurance. 



Ongoing maintenance of the 
physical data resource. 



Development Centre 

Projects with estimated 
effort > 10 days 



The Organization of Administrative Applications 
Figure 1 

Not really .'oiowing what was about to happen, we began. In an effort to engage 
everyone in the group, the notion that we might not be organized the best way was 
brought up at the our weekly "chat 11 . Successive chats didn't generate any new ideas; in 
fact, it appeared that nothing could be changed: everyone was focusing on the reasons 
why things had to stay the same. To break that impasse, at the next meeting a new or- 
ganization structure was proposed, one that would address the need for shareable data, 
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care of existing systems and would free some people for getting us out of the mess we 
were in. Everyone was asked to think about it, taUk about it and criticize it. It was a 
month before the subject was brought up again but after three months of discussion it 
was clear what the structure (Figure 1) should be. Most thought that it would not work. 
Worse yet, many thought that the energy to drive the transition did not exist. Regard- 
less, four months after suggesting that we consider changing our organization, we began 
operating with the new structure. 

The Application Resource Management (ARM) group is responsible for the long- 
term viability (maintenance) of applications. This includes our current application sys- 
tem legacy, until they are replaced, as well as new data acquisition applications that are 
developed. The co-ordinator of the ARM is, essentially, a product manager. While the 
manager of a development project's goal is to produce the product on time and within 
budget, the product manager has to live with the result. Therefore, the ARM co- 
ordinator is also responsible for software quality assurance. 

The complement of the ARM was chosen somewhat heuristically. An analysis of 
work completed in the previous three years showed that only two people were needed to 
keep the legacy systems running. However, that also meant no adaptive changes would 
be made to those systems. Since we knew that to make the change to an Information 
Resource Management approach would take a long time, we also knew that some adap- 
tive changes would have to be made. Therefore, we decided to have four people plus a 
co-ordinator. 

Led by our DataBase Administrator (DBA), the Data Resource Management 
group is responsible for managing the physical database environment and the data man- 
agement tools (our dbms and repository), maintaining the repository, and creating the 
physical data design on development projects. This group now has a compliment of two 
full time people. 

That meant that the remaining people could be assigned to projects in the Devel- 
opment Centre. There are a couple of characteristics of the Development Centre that 
should be highlighted. First is it's project orientation. The Development Centre only 
does projects and, hence, it has no staff - at least not at this time. When a project is 
mounted, a project manager is appointed who plans the work and is responsible for esti- 
mating each task. Once the project plan is approved by the sponsors, the best available 
people are assigned. These may be informaticians from the Data Resource Management 
or Application Resource Management groups or they may be from functional areas. 
When the project is complete, the team disbands and their product is managed by the 
ARM. 

This second characteristic, that the projects are usually multi-disciplinary, is im- 
portant because it provides a mechanism for cross-functional co-operation or collabora- 
tion. Both functional groups and information services are able to work towards a goal 
that is in the institution's interest rather than that of one group. Resources, usually hu- 
man, but sometimes financial, can be transferred to the project without one group feeling 
that it has lost to another. 
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The New Orientation. 

In general, we wanted to leave business re-design to the functional people. This 
doesn't mean that we couldn't help, but in order to be as effective as possible we de- 
cided that our greatest value would be in assisting them to analyze their business prac- 
tices and, particularly, in understanding which of their business processes were already 
being performed elsewhere in the institution. 

For example, recording a vendor's name and address couldn't be much different 
from recording a student's name and address — or a patron's, or an employee's. Conse- 
quently, if a database and function already exists for recording names and addresses then 
they can and should be used. Further, the institution's information services professionals 
are in the best position to know this. 

As mentioned earlier, this meant changing people's area of expertise and social at- 
tachments. For example, a Human Resources analyst, who was known and valued by 
the Personnel and Payroll departments, had to become a software scientist and engineer. 
That meant different expertise in information services and loyalties first to the Univer- 
sity and secondly to a functional area. People feel good about being the local expert in a 
particular area so we had to find new areas in which they would be recognized as 
authorities. 

Identifying new areas of expertise was not too difficult but before assignments 
could be made employee talents had to be carefully assessed and new skill development 
encouraged. It began with the understanding that, as Watts Humphrey wrote, we 
"...probably [had] about the best team we could get... While it is always desirable to re- 
cruit better people, it is also wise to focus on making better use of the people we already 
have. This always pays off." 

The first change was to create a Database Administrator (DBA). This was done 
by naming someone DBA unofficially and then changing a position's description when 
it became vacant. This position was vacated by a senior analyst who was more comfort- 
able furthering his career in a functional unit. When an organization goes through a 
metamorphosis such as we did, there are some that choose not to enter the next phase. 
This suited everyone well: first, he was able to provide needed business analysis in that 
area and, second, it provided us with a vacant senior position from which the DBA posi- 
tion was created. 

Next, we attended to areas of expertise. If we were to work in a project environ- 
ment, we needed project management expertise. To our great fortune we were able to 
hire a project management consultant half-time. Her contract specified that, rather than 
manage one or more projects, she was to tutor those that had responsibility for managing 
projects. Her job was to instruct those struggling to manage our projects, and she had a 
phenomenal effect. After she left, one of her proteges was named as our internal project 
management consultant. 

The second area of expertise is business analysis. We understand the role of the 
business analyst is to construct a a baseline or model from which change can be con- 
trolled. The change in this case is the re-engineering of a business areas. Although 




2o() 



■275- 



larger organizational units could afford their own business analysts, there are many that 
can not. To address this, senior people who had been marooned on functional islands, 
but who are analytically sophisticated, are now business analysis experts. 

Another area of expertise is emerging technologies of which one of the most 
quickly emerging is Object Orientation. We recognise that everyone wants to be current 
but we simply don't have the time for each person to be current with the latest methods 
and tools. Our object-oriented expert does, though. His job is to be current in what is 
obviously an important, albeit emerging, area and keep everyone informed. 

Finally, we have also created a toolsmith, someone who will be able to adapt the 
software tools we use so that they can be used as productively as possible. As Watts 
Humphrey wrote in his book, Managing the Software Process , n ...even the best profes- 
sionals need a structured and disciplined environment in which to do co-operative work. 
Software organizations that do not establish these disciplines condemn their people to 
repetitively solving technically trivial problems." On any project, much time is spent on 
set up, e.g. creating shared directories and libraries, setting protection codes, tailoring 
software tools and ensuring that all project members know how to use them. These are 
the types of jobs we have assigned to the toolsmith. 

Retooling. 

One of the most profound realizations we have come to is that we work together. 
That may seem obvious but as we began to retool it became apparent that many of the 
highly touted personal productivity tools were just that - personal. While making indi- 
viduals more productive they did little to promote group effectiveness. The most obvious 
example is personal time management — computerized or manual. While each person 
may be well organized, groups of people are forced to co-ordinate their time in the same 
inefficient ways they always have. 

Our retooling goal, then, was to create as collaborative an environment as possi- 
ble. Of course we wanted people to have as powerful tools as possible but these tools 
had to promote shared work. Constraints such as complexity or urgency forced us to col- 
laborate to solve a problem or create a software product. Consequently, we wanted to 
create a hardware and software environment that would, as Micheal Shrage puts it, "...al- 
low two or more individuals with complementary skills [to interact] to create a shared 
understanding that none had previously possessed or could have come to on their own." 

For hardware we chose multiprocessing workstations — V AXstations. Since the 
software we maintained and developed ran on a VAXcluster, it made sense for us to 
have VAXes on our desktops. With a 19 inch monitor many executing windows can be 
open. It is not unusual for an informatician to be working on four or five things at the 
same time. We have found that there is gain of two hours of productivity for each per- 
son per day. That means that four workstation-equipped informaticians do the work of 
five! 

The greatest reason for using VAXstations, however, was software. As part of it's 
program, "The Education Initiative", Digital Equipment granted campus-wide software 



licenses for all Digital software. Consequently, we have an extremely rich software tool 
environment. 

One of the most intriguing tools is for personal time management and project plan- 
ning. People, projects and facilities (rooms or any other physical resource that needs to 
be scheduled) have planners. The personal time manager appears as a calendar running 
on an individual's workstation and can then be used to perform the usual time manage- 
ment operations of booking meetings, defining tasks, and charging time. In addition, 
other peoples' and facilities' planners can be scanned ror availability. When a project 
manager assigns someone to a task, the assignment shows up in the informatician's plan- 
ner and the assignment can be negotiated. The same is true or charging effort expended 
on project tasks. 

Software of this sort promotes communication and co-ordination rather than com- 
mand and control. Note that rather than having people "reporting time 1 ' they are encour- 
aged to manage their own time. Time reporting, necessary for project control, is then 
added value to the empowerment of the worker. 

The Toolsmith. 

Changing the focus of the Administrative Applications group from individual sys- 
tems to the institution as a whole requires that there be staff with expertise in specific 
areas. As suggested earlier, this expertise is not in traditional systems; it is in cross- 
functional disciplines such as project management, estimation, methods and what we re- 
fer to as "toolsrrtithing": the adaptation of software and hardware tools and environments 
to increase the effectiveness of other information professionals. It is not possible for 
employees to be adept with all tools used to define, build and maintain software. These 
people work in sophisticated environments, using sophisticated tools. They often re- 
quire assistance since even bright, knowledgeable people do not use tools as effectively 
as possible or spend too much time "setting up" a project. The "toolsmith' 1 is responsible 
for maintaining, customizing and investigating software tools, and establishing standard 
environments to enable the Software Process. 

As defined by Watts Humphrey, "The Software Process is that set of tools, meth- 
ods and practices we use to produce a software product. The objectives of the Software 
Process are to produce products according to plan while simultaneously improving the 
organization's capability to produce better products." 

The goal of the toolsmith is to relieve other software workers from drudgery by 
co-ordinating planning, development and support methods, techniques and tools. On de- 
velopment projects, the toolsmith quickly creates a standard development environment 
that boosts the project team's productivity while supporting change control, and project 
planning and control. The Data and Application Management groups rely on the tools- 
mith to ensure that the software tools they use are up-to-date, integrated and as simple to 
use as possible. 



Our software engineering toolkit consists of the following tools: 

• An extensible editor that "knows about 1 ' languages (Language Sensitive Editor). 
In addition to giving language syntax assistance, one is able to compile pro- 
grams and review compiler errors, 

• A librarian (the Code Management System) for tracking and controlling 
changes to source code (programs, documentation, 4GL applications etc), 

• An application building function, (Module Management System) for simplify- 
ing and automating the building (compiling and linking) of applications, 

• A conferencing tool (VAXnotes) for tracking change requests and communicat- 
ing with clients and other staff, 

• A direct communication tool (VAXMail), 

• A document publishing application (DECwrite), 

• A windowing environment (Motif), 

• A project management application (DECplan), 

• A distributed repository of institutional information definitions and descriptions 
(CDD/Repository), 

• An analysis and design tool (DECdesign), 

• An application for organizing and automating regression tests (VAX Test Man- 
ager). 

"Toolsmithing" focuses on four categories, the first of which is extending the Ad- 
ministrative Applications environment. This means customizing the tools that are used 
to accomplish software definition and support tasks. The client's software environment 
is tailored during development but attention never seems to be paid to tailoring the de- 
velopment and maintenance environments. Software tools are acquired and simply used 
(often without reading the documentation). This does not maximize the benefits possi- 
ble with many of the available tools. 

By tailoring our tools we help increase productivity and maintain the standard 
practices that have been developed, The tools are thus used consistently for all tasks. 
This is important in an environment where each staff member is expected to support 
multiple information services. 

Much of our time as IS staff is spent editing such things as source code, mail mes- 
sages, memos, etc. Therefore, it makes sense that the most valuable tailoring would be 
made to the editor since we use it for so many different tasks. Several extensions have 
been added to our editor to ensure that it performs all the tasks we need it to do. This 
allows us to have standard features whether we are editing source code or composing a 
document. 

The second category is infrastructure support for projects. An important aspect of 
a successful project is that the environment be conducive to collaboration and that it 
conform to the standards of the group. The toolsmith's job is to create an optimized en- 
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vironment, so that analysts and developers can almost immediately begin their work. As 
well, the toolsmith may be able to spot and ameliorate difficulties with tool use. 

The third category is consulting support for staff. With short staffing it is nearly 
impossible for every staff member to keep up with all the new tools and utilities as they 
become available. Staff members with expertise in various different tools are known to 
be available as consultants to the remainder of the group. 

Monotonous tasks are often time-consuming, and are performed ineffectively by 
staff because they do not know a better way and do not have the time to investigate and 
learn one. By having a resource with expertise in the various tools, there is someone who 
can point them in the right direction and provide special purpose instruction, increasing 
the capability of highly paid, valuable staff. For example, when the database adminis- 
trator needed special editing to format database definition statements, a twenty minute 
consultation allowed the task to be completed within a half hour instead of the estimated 
one day. 

The final category is investigating the applicability of new tools. We have a large 
number of software tools at our disposal. We know that many of these tools would be 
useful in our work if we had the time to investigate them. By having a staff member 
whose job is to investigate these new tools and their applicability to the current environ- 
ment, the incorporation of new tools and ideas is made easier. 

Where a Toolsmith Can Add Value 

A model of our change management process was presented at CUMREC 91. This 
model is now used to illustrate the points where the toolsmith adds value by integrating 
various tools and providing a standard structure across applications. 

Figure 2 (on the following page) shows the context in which we manage software 
changes. As can be seen there are three sources of Change Requests. Clients are the 
functional users of the information systems. Informatician is a term defined earlier. We 
also have maintenance contracts with Software Vendors who, from time-to-time, send us 
bug-fixes or enhancements. These vendor supplied changes (VSCs) are also treated as 
change requests. 

Figure 2 also shows that both Clients and Informaticians discuss Change Requests 
by supplying Replies to them. These Replies are kept in context with the Change Re- 
quest and are concluded with a final reply, labelled as Summary. That briefly sums up 
the work and anything learned during the completion of the Change Request. Periodi- 
cally, an overall summary of change request work, labelled as Completed Tasks, is pre- 
pared and distributed to University Management. 
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Software Change Management 
Context Diagram 
Figure 2 

The highlighted portions of the process model (Figure 3) show where custom iza- 
tions and extensions have added value. 

Receipt of changes from vendors has been automated so that they arrive via Inter- 
net mail. The Vendor Supplied Changes (VSC) consist of two parts. The first part of the 
change (or mail message) is the Cover Sheet which contains the description of the 
change, i.e. which bug it fixes. The second part is the actual Details (the source code) 
of the changes. The Cover Sheet becomes the Change Request and is stored in an elec- 
tronic conference. The details are stored in a library since it is actual source code. The 
process of extracting the Cover Sheet and putting the details into the library has been 
automated so that the person on support can accomplish the task with a minimum of 
effort. The support person edits the VSC in mail, and, via a keystroke in the editor 
places the Cover Sheet into the appropriate Change Request Conference, and the details 
into the appropriate library (CMS). 
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Software Change Management 
Process Model 
Figure 3 
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Since applying the VSCs is simply a matter of cutting and pasting (along with 
some testing), automated procedures have been created to facilitate setting up the vari- 
ous libraries and loading the source into the editor's buffers to make cutting and pasting 
the changes easier. 

The creation of change requests has been customized by creating a change request 
language. This creates a template for the change request so that all of the appropriate 
information such as date required, requested by, etc. is present. As well, utilities such as 
a spelling and grammar checker have been added to the editor to make creating text for 
distribution easier. 

The actual changing of source code has been customized by adding several tem- 
plates to the Language Sensitive Editor to support the languages that we use (e.g. pre- 
compiled SQL, Digital Command Language, etc.). This decreases the number of syntax 
errors and supports standardization of coding style. Various utilities have also been 
added to the editor such as rectangular cut/paste, shifting text (helpful for placing text in 
an if-then statement), and a query for the cursor's current line and column position. 
These extensions are available to all programmers; not just used by the clever person 
who developed them, usually in his spare time. 

At the U. of S. we store programmer documentation in Help libraries which are 
used in the office or from home. Individual topics are stored as text files in our CMS 
library, but rebuilding the Help libraries is time-consuming and boring. Consequently, 
this final step was often put off, leaving the help libraries not up-to-date. To ensure that 
the documentation is rebuilt, a local "event handler" has been written. Whenever a 
specified event occurs (in this case the replacement of a documentation element) CMS 
invokes a user-defined routine. By having CMS invoke another utility that reassembles 
the online help library, the toolsmith has automated and standardized this process. 

In the change management process there are change requests generated by Ven- 
dors, Clients, and informaticians that are stored in a VAXnotes conference. The state of 
each change request must be managed, i.e. it should become a task in our Task Manage- 
ment Database (Project Management system). With the large number of change re- 
quests, manually creating these tasks is cumbersome and error-prone. This was another 
place where a little assistance would boost productivity and quality (we didn't want to 
lose any change requests). A procedure was created which looks at all conferences and 
extracts the new Change Requests. It then filters these change requests to determine 
which are tasks that must be defined, prioritized and scheduled and which are support 
issues. The procedure then creates the tasks in the Task Management database (with the 
appropriate CR identifier). 



9 

ERJC 



Predictions for the Future, 

The rapid change in price and performance of computing hardware, coupled with 
equally dramatic forces for change at the University of Saskatchewan have driven the 
Administrative Applications group to profoundly alter its business practices. Those 
forces will not diminish and may even escalate. Consequently, while ten years ago we 
were just trying to get students registered or financial reports produced within two weeks 
of the month's end, we now are trying to enable students to register from anywhere in 
the world by telephone and department staff to enter Purchase Requisitions from their 
desktop computers. 

In order to manage that change, however, we will have to develop architectures: 
explicit ways to depict what should should happen in order to co-ordinate the creative 
efforts of a number of people. People that develop architecture are known as architects, 
so in order to address these needs the future information organization must include data, 
process (business), and technical architects, in addition to the infrastructure support peo- 
ple mentioned earlier. 

Finally, new methods of funding will have to be developed to support this plan- 
ning cadre. We think, though, that as business processes are re-designed and begin shar- 
ing already existing information resources, the savings will be so great that the question 
will become, "Can we afford not to invest in new services that share data?" However, 
the actual methods of accumulating that investment for the building of shared informa- 
tion have yet to be worked out. 



Footnotes 

1. Humphrey, Watts S. Managing the Software Process. Reading, MA: Addison- 
Wesley, 1989, p. 26. 
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Random House, 1990. p. 40. 
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During the last six years, the University of Texas at 
Houston Health Science Center (UTH-HSC) has developed a 
TCP/IP based, open systems network that currently 
interconnects over 2,300 computers. This network 

(UTH.TMC.EDU) continues to expand at a rate of about 200 
nodes per month and is part of the larger Texas Medical 
Center Network (TMC.EDU) that includes over 4,000 Internet 
nodes. The goal is to create an integrated information 
system that maximizes the sharing of all computer based 
information. This system must provided information from 
local as well as international sources directly to 
individuals as needed, and evolve as technology and 
standards change. It must also allow information to be 
easily added to the system by its users. 

The TCI /IP based UTH-HSC network began in response to 
federal initiatives designed to standardize on a single 
transport protocol for research funded by the National 
Science Foundation (NSF) and by the National Institutes of 
Health (NIH) . Concurrently, most Unix workstations that 
were commercially available were being shipped with Ethernet 
ports and TCP/IP software. A general recognition began to 
emerge indicating that it might be possible to use the basic 
TCP/IP protocols to provide a set of common information 
services among virtually any type of computer. These 
services included: the simple mail transfer protocol (SMTP) 
for electronic mail; telnet for vtlOO and tn3270 terminal 
access to remote hosts; the file transfer protocol (FTP) for 
the exchange of ASCII and binary files; and the network file 
system (NFS) for client/server based file exchange. As the 
TCP/IP based local area networks (LANs) started to appear 
within the Texas Medical Center (TMC) , the University of 
Texas Office of Telecommunication provided links for these 
LANs to become integrated within the Internet. This access 
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allows the same protocols for information sharing that were 
being used locally to be used world-wide. 



With several existing LANs and wide area networks 
(WANs) on campus and the promise of more soon, it was 
obvious that there was a demand by students, faculty and 
staff for Internet access. A number of administrators and 
users were realizing the feasibility and convenience of 
"posting" document on the Internet rather than dispersing 
the information using traditional methods. Thus, the idea 
of implementing a campus wide information system (CWIS) 
emerged. 

To meet the immediate demand for the distribution of 
ASCII based documents, an in-house developed system was put 
in place. This home-grown CWIS consisted of script files 
forming a menu based system. The system was accessible only 
through terminal access either via an anonymous telnet 
session or dial-up phone lines. The menus and associated 
processes were "hard coded" using Unix script commands and 
were not standardized. Protocols such as FTP, REXEC and NFS 
were driven by script or C programs to automatically obtain 
information from other Internet : ies for incorporation into 
ASCII files for distribution. However, no attempts were 
made to integrate the UTH-HSC CWIS, as a whole, with other 
campus systems. 

The initial CWIS clearly demonstrated to the campus 
community that a distribution system that primarily 
delivered ASCII text had valuable potential. In particular, 
it was recognized that (1) users would always know where to 
look for information, (2) desired information could be 
accessed from any Internet node, (3) updated information 
would be immediately available, and (4) publication costs 
would be drastically reduced. Although these strong points 
were appreciated, the system definitely had shortcomings. 
It suffered in that (1) it could not be efficiently 
maintained, (2) it did not adhere to a user interface that 
was standard for similar information systems, (3) its 
existence was not readily visible to the world, (4) it 
provided no standard method to transparently access other 
functionally similar information resources, and (5) it was 
not a client/server based system that coupled the resources 
of personal computers with those of information servers. 

As these advantages and limitations were being 
considered, the Wide Area Information Service (WAIS) system 
was developed by Thinking Machines Corporation, Dow Jones & 
Co., Apple Computer, and KPMG Peat Marwick. This 
client/ server based system permits clients on both personal 
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and larger computers to access text, images, voice or 
formatted documents located on WAIS servers. As a 

searching tool, WAIS makes finding relevant text in a 
document s impl ist ic . For instance , if you were to 
traditionally search a book to determine if it contained 
information on a specific subject, you would search the 
title, table of contents and the index. Through this 
search , you may or may not f ind the one term, obscure or 
not, that you wish to locate. If this same text is indexed 
into a WAIS database, the WAIS search engine and not the 
researcher does the work. The WAIS indexing process 
categorizes the words and makes all words of the entire text 
accessible for search, with exclusion of articles, 
conjunctions, etc. Combinations of words can even be used. 
In cases where phrases are submitted for search, the WAIS 
search engine responds with as close a match to the entire 
phrase as it is able to make then lists all references that 
contains each of the individual words. On some clients, the 
search terms are highlighted in the text. WAIS is used for 
searching all types of text: phone books (where you can 
search for references by first name as well as last name, or 
phone number or city, etc) ; or large text documents (where 
you can search for any word or phrase in the document) . 

While WAIS is an excellent tool for searching if you 
are looking for specific data, the system of WAIS servers 
also has weaknesses. For example, the list of WAIS sources 
has grown by leaps and bounds. Although there is a list of 
registered sources, no hierarchial menu exists that groups 
the sources by subject. Also, you cannot just peruse the 
text without first trying a word search. If you just want 
to read a small portion of the text, WAIS is not the tool to 
use . But, if you want to search a 300 page book to see 
where the animal "ferret 11 is referenced as a laboratory 
animal, WAIS will deliver a detailed list quickly and 
accurately. 

For the University, WAIS became a dynamic tool. The 
university office of Information Services along with Human 
Resources and Employee Relations pulls together information 
on all employees including: names, departments, home and 
work addresses, phone numbers etc. This information used 
with the WAIS tool allows anyone with Internet access to 
search Centrex, the campus phone book to locate an employee 
or employees by name or other descriptive information. The 
Office of Research Services gathers information on all 
active labs, the research being done, papers written, 
animals and chemical used, etc. and compiles this 
information into the Catalog of Research Expertise . With 
the WAIS system, researchers on or off campus could find 
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UTH-HSC labs working with any variety of chemicals, 
techniques or animals. The Purchasing and Receiving 
Departments have used a similar process to help researchers 
and staff locate hazardous material numbers. This is just a 
few examples of where the WAIS system has demonstrated its 
usefulness at the Health Science Center. 

As a stand alone system; however, WAIS does not provide 
a basic , integrated CWIS system . In particular , the 
protocol does not provide for a standard user interface that 
appropriately organizes documents and services in an 
hierarchical manner that can readily be perused according to 
subject. The protocol also does not specify a standard, 
intuitive method for adding available sources to WAIS 
clients. In order to partially resolve these problems, text 
and X-window based WAIS clients were implemented on the host 
supporting our initial CWIS. This approach allowed users to 
be directed by the CWIS menus to appropriate WAIS sources. 
However, this approach negated the important advantages 
associated with having clients running on personal computers 
so that information is directly and transparently delivered 
to the desk top. 

Since the demand for a more functional, expanded CWIS 
continued to grow, we systematically began to investigate 
the efforts of other universities and groups to develop a 
standard CWIS protocol. As a result of this investigation, 
it was concluded that the Gopher Protocol for document 
distribution developed by the University of Minnesota would 
be used to implement a new CWIS for the Health Science 
Center. This protocol was selected for a number of reasons. 
For one, users see the world-wide networked system of Gopher 
servers as a single hierarchical system of documents, 
directories, full-text search tools and other services. 
Secondly, it is a client/server based system that enables 
users to easily and transparently access servers anywhere on 
the Internet and functionally transfer data to their 
personal workstations . Thirdly, it incorporates a well 
defined set of standards for defining data types, 
establishing connections between servers, transferring data, 
1 inking menu entries to data files , etc . Fourth , it is 
becoming a de facto standard for universities and other 
organizations that utilize the Internet for the rapid 
exchange of digital information. Lastly, Gopher is a 
recommended protocol for document distribution within the 
NSF Implementation Plan for Interagency Interim NREN. 

Our Gopher based CWIS was activated in March, 1992. 
Users were immediately impressed with the systems ease of 
use and simplistic design. Gopher requires virtually no 
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training for access or use of the system. One of its best 
selling points is its connectivity. Gopher servers, once 
listed by the Minnesota Gopher, are all capable of being 
interconnected. To move from one Gopher server to another, 
the user merely chooses a different topic. The addressing 
and other connectivity issues are all invisible to the user. 
It is as though any information available via ANY Gopher 
server resides on the user's personal computer. Files can 
be mailed, saved to disk, or printed by an average user, 
without training. 

The conversion of the CWIS at UTH-HSC to Gopher 
necessitated the creation of an editorial staff and new 
document publishing tools. The staff consists of an editor 
in chief that oversees all work. Other staff members have 
responsibility for various pieces of the whole. It is 
imperative that the group work as a team, rather than 
holding tightly to their own piece of the pie. Our 
experience confirms that of Art. St. George, Executive 
Network Services Officer, at the University cf New Mexico, 
that the editor in chief should not be a programmer, but 
rather a "people" person. This helps negate the 

possibility that the end product is only geared toward 
computer proficient users. The CWIS must be easy to use and 
attract non-traditional computer users. In addition to the 
editor, the team should include a programmer and a design 
consultant. With such a team, the end product will be 
useable, effective and aesthetic. 

The editorial staff has several responsibilities. One 
of the primary responsibilities is to maintain a state of 
the art electronic publishing environment. This requires 
the staff to evaluate and implement: (1) document 
distribution protocols; (2) publishing servers; and (3) 
reader clients. When required, appropriate software tools 
to support publishing activities must also be developed. 

A secor^ esponsibility is the layout and production of 
the CWIS. 1 includes assisting the information owners in 
defining appropriate text for distribution, as well as, the 
menu and submenu categories. When campus groups become 
interested in publishing new information on the CWIS, some 
editing requirements are necessary. While we agree to hand- 
hold the information providers in formatting the documents 
for publication, it is important to note that the 
responsibility for producing ASCII documents lies in their 
hands, not the OAC staff's. A list of the standards that we 
have set are below, along with the reason for each of these 
standards . 



* Avoid the use of tabs , instead use spaces . Reason : 
ASCII tabs are not converted to a constant number of 
spaces by all display devices. Thus, the use of ASCII 
tabs often causes text to be displayed in a jumbled 
fashion . 

* Delete bullets or other special symbols such as Greek 
characters and/or replace with standard ASCII 
characters . Reason : Character based terminals can 
only display ASCII symbols. 

* Single spacing of lines, but double spacing between 
paragraphs. Reason: Maximizes the amount to text that 
can be displayed per screen** while preserving 
readability. 

* Use a non-proportional font and limit line length to a 
maximum of 78 characters per line. Reason: If all 
characters do not take the same amount of space, it is 
difficult to ascertain whether each line has less than 
80 characters or not. Lines that exceed the 80 
character limit will either wrap improperly or run off 
the screen. If each letter takes up the same amount of 
space, the problem of wrapping lines or lines running 
off the page are avoided. 

* Place headings in capital letters and text in up/down 
casing. Reason: Enhances the identification of the 
beginnings of thoughts and divisions of chapters, sub- 
chapters, etc. 

* Place identifiers around headings (dashes or equal 
signs) . Reason: Enhances the conceptual readability of 
the material. 

* Prepare text in a neat, orderly and easy to read format 
for both paper and electronic formats. Reason: For 
first drafts we suggest submitting both a hard copy and 
an electronic copy in case there are errors in the 
formatting. 

* Place a line of 50 dashes before each section of 
material if the denoted sections are to be indexed into 
a WAIS source as separate documents. Reason: The WAIS 
indexing tool can be configured to use dashes instead 
of other delimiters, such as blank lines, to identify 
where WAIS documents are to start and end. 

When ASCII documents are appropriately formatted, the 
editorial staff assists in creating or modifying existing 
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menus and assigning menu ownership. Owners of information 
are often provided with appropriate tools that enable them 
to self -publish their material via the CWIS. 
If necessary, the staff will enter the information for the 
owner until tools can be created. 

The editorial staff is also responsible for monitoring 
the overall look-and-f eel of the CWIS. These activities 
include (1) confirming that menu pointers to remote 
information sources remain functional , (2 ) ensuring the 
general availability and timeliness of documents, (3) 
checking the functionality of WAIS sources, and (4) 
guaranteeing the adherence to certain basic standards* These 
standards include conformance to the formatting guidelines 
for ASCII text, the inclusion of ownership information 
within documents, conformance to copyright law, and the 
general readability of documents. 

It is also important to realize that the editorial 
staff must assume certain public relations responsibilities. 
The "reader" base must be expanded by advertising, assisting 
users, analyzing usage trends and responding to user 
suggestions. The publishing service must also be actively 
promoted by contacting possible information providers, 
demonstrating both user and publishing aspects to various 
individuals and responding to queries about the publishing 
capabilities of the CWIS. 

Publishing tools have been developed to enable users to 
directly publish information from either their desktops or 
from mainframe hosts. One of our publishing tools is called 
"mailman." Mailman was developed to permit users to publish 
ASCII documents directly via e-mail. The process begins 
when a document is created for publication. Before 
publishing, the document must be converted to ASCII format. 
Then, it can be mailed to the user "gopher" (or another 
specified user id) on a computer that is running the Gopher 
server daemon. (A deamon is a utility program that runs in 
background on the server awaiting queries from Gopher 
clients . ) Mail received by the host that is addressed to 
this designated user id is sent to the "mailman 11 program. 
The "mailman" checks to determine if the person sending the 
message from that particular host is in a list of approved 
user/host pairs that has permission to remotely publish 
information. If the userid@host .domain is included on this 
list, "mailman" checks the subject field of the message to 
determine where in the hierarchial Gopher system the 
information is to be placed. In other words, the Mailman 
program checks to see that the user id, host. domain name and 
subject heading all match. If all checks out, the ASCII 
file is published. As an added security for quality work, 
Mailman then sends e-mail to the editor of the CWIS, with 



information on which files have been updated. This will 
allow for checking of quality and format. A diagram of this 
process is shown in Figure 1. 

A second publishing tool was produced to deliver 
information from mainframe computers. This tool allows for 
direct and automatic publishing. When a report is 
generated, either at set intervals or upon demand, they are 
converted to ASCII text files from the appropriate data 
bases located on the mainframe computer. The ASCII file is 
then retrieved by a Unix based computer using the FTP 
protocol, Once on the Unix server, the MakeWAIS tool 
indexes the data into a full-text WAIS source. Like all 
WAIS servers, the file is now completely searchable. 

When WAIS creates a WAIS server, the program produces 
several files. These files need to be moved to proper areas 
in the Gopher client. The MakeWAIS tool moves all of these 
files. If the information becomes obsolete, the CleanWAIS 
tool retrieves all of the various files for that database 
and removes them from the system. This process is 
illustrated in Figure 2. 

As the system develops, new tools will need to be 
created in order to help users publish with ease. It is our 
opinion that any new tool that requires an entire pamphlet 
of instructions, should never be given to a user, but rather 
filed away in file 13. The elegance of the Gopher protocol 
is a model of ease and useability that should be copied. In 
Figure 3, you will see that several groups are now providing 
information through Gopher servers to the UTH-HSC. These 
interconnected servers maximize the amount of information 
made available to our users with distributed workloads. No 
one group need provide all information, nor is it necessary 
to reproduce the work of others with the Gopher client makes 
pointing to other sources such an ease. 

The Campus Wide Information System at UTH-HSC changes 
daily and will continue to do so. That is an asset. 
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INTRODUCTION 

This paper presents the three steps Administrative Information Services (AIS) is 
following to provide Michigan State University's clients with a new data access 
architecture. This architecture will be comprised of comprehensive data reporting 
structures, non-mainframe database software with user- friendly tools, and training on both 
tool use and the meaning, format and location of reporting data. Cur strategy can be 
described with three key words: data, tools and training. Due to the phased 
implementation and sheer size of MSU's new Student Information System (SIS), we have 
taken a "data first" approach. Flat-file extracts of selected portions of the database have 
been created for use in our current Client Based Computing environment and training on 
these extracts for MSU's administrative units has been completed. The growing 
sophistication of our clients' computing requirements, the proliferation of campus and 
local area networks, and the power of the desktop workstation are the driving forces 
behind our final goal which i<- to move these extract flics to an alternate platform for 
client access. 



BACKGROUND 

Michigan State University was established in 1855 as the nation's first land grant 
institution. Located in East Lansing, MSU's park-like campus encompasses 5,200 acres 
and includes nearly 150 buildings. The University has an enrollment of about 40,000 
students in undergraduate, graduate and professional degree programs. 
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Administrative Information Services (AIS) reports organizationally to the Vice 
Provost for Computing and Technology. The mission of AIS is to provide leadership in 
the administrative use of information technology capabilities that contribute to the 
University's mission of teaching, research and service. 

Administrative Information Services* 150 employees serve administrative support 
and academic administration units and their constituencies, faculty and staff, students and 
other organizations that contribute to the University's mission. The AIS Data Center 
houses an IBM 3090 model 300J processor running MVS/ESA. AIS utilizes both 
IDMS/DC and CICS for administrative application software access. 

"End User Computing" at Michigan State University is referred to as Client Based 
Computing (CBC). MSU has a large and active CBC community: more than 200 
individuals have been trained in mainframe-based reporting languages such as SAS and 
DYL 280 II. Client programs are created and submitted through the ISPF-likc editor 
SYSD accessible through CICS. Job and program outputs are reviewed prior to print 
through the use of SAR which is made available at the VTAM menu level. The MSU 
CBC community executes in excess of 87,000 batch jobs per year on the AIS mainframe. 
In addition to these ad hoc queries, clients create programs for regular execution as pan 
of the daily batch production schedule. 

CBC "beyond the mainframe environment" describes a large and rapidly growing 
demand for information delivered to alternate platforms for local processing. Recent years 
have seen tremendous growth in the campus Ethernet network, local area networks and 
desktop workstations. 

AIS' challenge to support our clients and their requirements to have information 
available in a timely manner and in an easy-to-use format is being met by concentrating 
on three fronts: 

* First, data must be available to support a variety of reporting needs and 
must be accessible yet protected from unauthorized access; 

* Second, tools must be provided which serve the needs of our most 
sophisticated clients as well as the needs of infrequent and/or less skilled 
users; 

> And third, training on both the tools and the meaning, format and 
location of data must be provided. 

The following sections describe the catalyst that launched our search for creative solution:; 
to address these issues as well as our progress to date and future plans for each of the 
f hree steps. 
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THE MSU STUDENT INFORMATION SYSTEM: A NEED FOR CHANGE 



Michigan State University has recently completed the initial replacement of its 
collection of isolated student record applications with a comprehensive and highly 
integrated Student Information System (SIS). SIS encompasses Admissions, Enrollment 
and Registration, Financial Assistance, Financial Records and Academic History. The 
software base consists of SCT and SIGMA packages which have been customized to meet 
MSU's requirements. SIS is made up of 615 online maps, 853 ADS/O dialogs and 550 
batch jobs. 

In implementing SIS, the University is moving from a series of application 
specific files with a variety of file structures and organizations which arc very familiar to 
our clients to a complex CATDMS network database consisting of 457 record types, 
1 1 ,000 data items and 718 physical record relationships (sets). The database, which has 
not reached its ultimate size, currently consumes 37 gigabytes of DASD storage. 

Due to the complexity and size of the new database, direct access by clients is 
untenable. Not only would most of our clients find the database navigation required to 
satisfy their reporting needs too difficult, the sheer volume of records which would be 
read would cause resource contention problems for the online application. Add to these 
concerns the fact that much of the data is stored in an encoded format and that many of 
the student classification structures have been changed with the new system. 



5/5 DATA ACCESS SERVICES (DAS) 

In an effort to pro-activcly address the difficult client computing issues raised by 
the implementation of SIS, MSU created the SIS Data Access Services (DAS) function 
within Administrative Information Services. This function's charter is to denne, articulate, 
and advocate a coherent SIS data access strategy. 

The primary goals and objectives of the SIS Data Access Strategy arc: 

► To isolate the client programmer from navigation of the complex and 
voluminous SIS database by creating host-based SIS reporting data 
resources; 

► To position SIS reporting data resources for future client/server or 
distributed database applications; 

► To provide tools which allow for routine or recurring retrieval requests 
to be met effectively and efficiently; 
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► And to foster, encourage and enable a greater degree of client 
independence through a strong program of education and support. 

The SIS Data Access Services team is staffed with four permanent positions, one 
graduate assistant, and two student programmers. The team is supervised by a Senior 
Systems Analyst Permanent staff includes one Systems Analyst and two 
Programmer/Analysts. Students are employed at half-time. 

Organizationally, the SIS DAS Manager reports to the AIS Student Information 
Systems Manager who also carries the title of SIS Project Assistant Director. This 
position reports jointly to the SIS Project Director and to the AIS Assistant Director of 
Information Systems and Services. Like AIS, the SIS Project reports to the Vice Provost 
for Computing and Technology. 

The Data Access Services team works closely with the University Data Resource 
Administrator, the SIS Project Team, and several areas within Administrative Information 
Services: access to client extracts is controlled through Security Administration; 
Database Administration provides assistance with IDMS retrieval, subschema development 
and extract performance issues; and client computing performance, tool and environment 
issues are managed by Help and Support Services. 

MSU/SIS: THREE STEPS TOWARD DISTRIBUTED DATA ACCESS 

The Student Information System is a very large application and affects every 
office across campus which interacts with students. As may be expected of a project of 
this scope, SIS has been implemented in phases over the past two years. Our clients 
however, could not simply stop and wait for AIS and the SIS project team to design new 
reporting files or to select and implement new non-mainframe database software and tools. 
Their work had to proceed uninterrupted as each new phase of the application was moved 
into production. 



STEP ONE: THE DATA 

A project to establish a distributed computing environment at MSU is 
officially just beginning. Due to the circumstances of the SIS project, MSU has 
taken a "data first" approach to providing this environment. Since its inception, 
SIS Data Access Services has been working toward the long-range goal of re- 
engineering selected data from the SIS network into a relational format more 
suitable for reporting. 



A lack of vendor supplied reports requires that a large number of 
operational reports be produced by client staff through the CBC environment. 
Thus, each of the project phases required that data converted to SIS be made 
immediately available to CBC. Without initially taking a general approach to 
data resource design, project phasing and the requirement for immediate access 
to SIS data would have combined to created patchwork of single-function data 
resources. 

Effective data resource definition and design is a highly cooperative 
venture involving the University Data Resources Administrator (DRA), 
representative client offices, SIS project team members, and SIS Data Access 
Services staff. Early and persistent involvement of client office managers and 
programmers is key to developing a sense of client ownership of the data 
resource. 

Data resource design begins with data analysis. The first phase of this 
analysis was to review how key client offices such as Registrar, Admissions, 
Financial Aids, Controller and Institutional Research were using the pre-SIS 
systems' data for reporting and analysis. Additionally, discussions were held with 
project team members and client office staff to determine how the new 
application's data might be used for production reporting, interfaces and client 
computing. Data analysis activities led to the conclusion that while a subset of 
the database population would suffice for reporting, a subset of the database 
content would not DAS subsequently concentrated on pulling most of the data 
elements on the database into extract files. This was done by basically "de- 
normalizing" the SIS physical database into logical entities in order to create a 
logical model. 

Client-driven data resource design followed the creation of that logical 
model. Client Design Workshops were held involving a large group including 
DAS, the DRA, SIS project team members and most importantly, client 
programmers and managers. Workshops were scheduled to include between three 
and six four-hour sessions. 

At the workshop sessions, the logical model and attribute list were 
discussed at length among workshop participants at a pace which allowed all 
involved to reach a common level of understanding. Workshop discussions were 
centered around relational design techniques such as the resolution of repeating 
groups, the identification of primary and foreign keys, the review of controlled 
redundancies, and the determination of the operational population. 



ERLC 



-305- 277 



Due to the extraordinary volume of the SIS database, extraction of the 
entire database population on a daily basis for reporting is not feasible. Rather, 
SIS DAS has endeavored to identify and isolate the subset of the database which 
represents the operational layer of the data. At MSU, data collected over the past 
two years is adequate for the vast majority of reporting requirements. 
Institutional research and specialized longitudinal, retention and trend analysis 
reports require the use of a wider span of data. For these purposes, a twenty year 
history of activity is extracted to tape on an infrequent basis. These types of 
studies can also utilize data frozen to tape for official reporting purposes. These 
database snapshots are taken each semester at specific times such as close of 
registration, first quarter of semester and end of semester. 

SIS is largely driven by tables and encoded data values. While making 
the online system highly flexible and responsive to institutional change, accurate 
reporting from familiar flat-file structures is infeasible. SIS employs in excess of 
100 tables of data and related processing flags. To address this situation, SIS 
tables are extracted daily and stored together in a direct access VSAM file. 
Clients have been trained in specifying table number and table key values when 
accessing the file for table data. Once VSAM processing had been introduced to 
CBC with support and training established, other uses for direct access could be 
considered. Several key files have since been created with both sequential and 
VSAM versions in order to provide multiple navigation paths through the 
"relational table" extract file structures. 

The consensus of the clients on the designs of the reporting extracts was 
critical. We also believe that the SIS reporting data resources meet the original 
goals and objectives set forth, including effectively positioning the data resources 
to move to the distributed computing environment without additional design or 
revision. 



STEP TWO: THE TOOLS 

During the phased implementation of SIS, it has been imperative that 
clients be able to continue using those programming tools and techniques that 
have been available to them for years. Due to significant changes to the types 
and formats of the student data being stored, it is not possible to "backload" all 
the familL/ files that were the outputs of our older non-integrated systems. 
However, by training the clients in the new data available on the extract files, 
they have been able to make a reasonably rapid transition to the new data 
environment. Similarly, several clients, who over the last several years have been 
able to download information to their desktop workstations, are able to continue 
this activity after training on the data. 
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One objective of SIS Data Access Services is to provide data 
manipulation tools which allow for routine or recurring student information 
retrieval requests to be met effectively and efficiently. Significant data activity 
analysis revealed that a very large percentage of requests for student information 
could be met through a relatively limited number of standardized retrieval utility 
programs. 

Today, ten utility programs have been developed to produce listings, 
labels or files for data transfer. Files can take the foim of tape, diskette or FTP 
transfer datasets. These ten utility programs have virtually replaced over 800 
centrally maintained "recurring request" programs which manipulated old student 
systems data for lists, labels and tapes. While specifically designed to support 
academic unit processing, the utility programs have also proven useful for 
providing infonnation to campus groups and third-party organizations outside the 
University. 

A new project, a cooperative effort of AIS and the Computer Laboratory 
(academic/research computing), is using existing staff and hardware/software 
resources in a "proof of concept" pilot for a new reporting architecture. The goal 
of this project is to load selected SIS extract data to a Sybase database currently 
available in the Computer Laboratory. The projict will incrementally develop 
from a server-based reporting model of minor complexity to a client/server model 
loaded with somewhat more complex data structures. This project will serve to 
highlight the issues and challenges which we will face as we begin evaluating 
hardware platforms and supporting database and reporting software to support 
campus wide access to SIS data. 

As we begin our evaluation of the optimal hardware platform, database 
server and reporting tools, we have the following objectives. First, SQL-based 
reporting tools should be independent of the database chosen. Second, the 
database should be independent of the operating systems of the wide assortment 
of desktop computing workstations already in place across the MSU campus. 
Finally, the operating systems should be independent of the hardware platforms. 
These objectives are simplified and are perhaps overly idealistic. However, the 
more "open" the various components are, the greater the likelihood that our 
clients will be successful working within the new reporting environment and that 
AIS will be able to provide the support that they need. 

Moving much of the client data access activities to a non-mainframe 
platform will allow our clients to utilize powerful PC-based tools. Plus, since the 
hours of availability of the mainframe (normally 7:00 a.m. to 6:00 p.m., Monday 
through Friday with some weekend hours when possible) may not meet the needs 
of client offices who often work outside normal business hours, the availability 
of alternate computing platforms should be much more flexible. 
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STEP THREE: TRAINING 



One key objective of SIS Data Access Services is to enable a greater 
degree <rf <^ient independence through a strong program of education and support. 
Extensile Encoding of data in SIS creates a vastly different programming 
challenge than was the case with the "old" student systems. In addition, 
classification structures such as level, curriculum, and major changed significantly 
in both meaning and use. These factors combine to forever change the 
"language" of student data and reporting at MSU. 

Three elements make up the essence of the SIS data resources training 
and support program: metadata documentation; classroom experience; and on- 
going customer service and support. In addition to the training and support 
program, frequent informal contacts with active clients is an important element 
of maintaining client confidence in the SIS reporting data resources. Consistent, 
informal client "account management" is also important for managing client 
expectations and for minimizing client crisis situations. 

► Metadata, or data about data, is an area of extreme importance. Clients 
must have documentation in order to successful!) and fully utilize the SIS 
reporting data resources. Documentation created to date includes a client 
data resource reference guide. The reference guide includes file layouts, 
file summary information and navigation paths through various extract 
files. 

► File layouts include element name, size and type along with a brief 
description of the meaning of the element. Additionally, fields which can 
be used as foreign keys to other extract files are marked. This includes 
code fields which can be expanded through accessing the common SIS 
table file (VSAM). 

► File summary information includes dataset name, record length, 
recommended blocksize and file size information in terms of the number 
of records normally in the file. In addition, if both sequential and VSAM 
versions exist, this is noted in the file summary information. Any special 
programming considerations or processing tips are also documented here. 

► Navigation paths from extract files to the table file and between extract 
files are al^o documented for client programmer use. Navigation path 
diagrams resemble entity-relationship diagrams with foreign key 
relationships highlighted. The client data resource reference guide is 
distributed to client programmers as they attend training sessions. 
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Future documentation directions include placing the data resources 
reference guide into a shareable medium. The development of a comprehensive 
data "encyclopedia" is seen as a primary requirement as we augment SIS metadata 
documentation. DAS research has indicated that an interactive encyclopedia, with 
a place for client comments and tips, is an important goal. 

Classroom experience currently utilizes the lecture /lab approach common 
to technical training. Training has been focused to date on central support offices 
and has followed the phasing of the SIS implementation. As phase-related 
extracts are implemented, key client offices are trained in the format and use of 
the data. Classroom sessions have been videotaped to allow for repetition without 
convening a full class. 

An academic unit training initiative is beginning which will provide 
training and documentation to currently active academic CBC programmers, 
DYL 280 II and SAS language training courses are currently being tailored for 
the academic community, focusing on the language components required for 
successful SIS-related computing. A future training initiative will be to convert 
training materials to a more interactive and selective platform. HyperCard will be 
investigated as a means to deliver high-quality training on specific topic areas or 
data issues. 

Academic or support units wishing to establish a CBC function, or 
wishing information about SIS reporting in general, can request a SIS Reporting 
Consultation. DAS staff consult with the unit on available SIS reporting options 
including establishing or expanding the CBC function within the unit. A training 
curriculum is recommended to include language or tool training, SIS online 
training and SIS data resources training. Further, assistance can be provided in 
the search for and selection of unit CBC staff. 

AIS Help and Support Services provides an important component of client 
support. The Help and Support Center can be reached through phone or campus 
electronic mail. First-level support, problem logging, and problem tracking are 
the essential services of the Help and Support Center, SIS DAS provides second- 
level or expert support on referrals from the AIS Help and Support Center. 

While data resource training has been established, tool related training 
will be required once the distributed computing project reaches the point of 
implementing selected platform and software solutions. Help and Suppon 
Services staff are represented on the distributed computing project in order to 
develop expertise prior to the need to deliver day-to-day support of the tools and 
data of the distributed computing environment. 
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We have discovered that training and support can be more effective by 
involving client staff and managers in every step of the project. Frequent client 
involvement through design workshops, formal client meetings, and informal 
client "account management" can build a sense of ownership and intensify client 
participation in training activities. 



CONCLUSIONS AND THE FUTURE 

By concentrating on creating general purpose data extracts, we have been able to 
avoid creating a multitude of unrelated reporting files specific to a particular client's 
requirements. The physical structure of our extract files also positions us to be able to 
move data to a new platform and database management system at any time. In addition, 
training clients on the uses, meaning and location of data within the existing environment 
should make a transition to new tools on a different platform somewhat less traumatic. 
An unexpected bonus of delaying the search for non-mainframe database software and 
tools has been that the market has ha^ - chance to mature. Vendors are announcing more 
"open" versions of their software and tnis trend is expected to continue. Since MSU has 
such a heterogeneous mixture of networks and desktop workstations, this delay will 
probably make it cheaper and easier to supply hardware and software solutions that will 
work across the entire campus. 

We believe that success with a distributed database reporting architecture for SIS 
clients will allow us to expand this service to other clients who currently work with 
Human Resources, Financial, Budget and Alumni Development data which is still 
available only through the AIS mainframe. Indeed, these clients currently submit many 
more CBC jobs than our major SIS clients. Today, even though SIS has not been 
implemented in its entirety and not all potential clients are accessing the system and/or 
data extracts, CBC jobs on the mainframe sometimes suffer from throughput that is less 
than ideal. Certainly, this is not in the best interests of our clients: our goal is to provide 
the information they need as quickly as possible. 

We also hope to provide the same types of documentation and training for current 
applications to our non-SIS clients and to introduce those clients to new tools on alternate 
platforms which will allow them to increase their productivity and effectiveness. How 
wc structure AIS to accomplish these goals is currently under discussion. For now, we 
arc concentrating on the Student Information System's data resources, on its reporting and 
manipulation tools, and on ongoing client training and support. 
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Rapid technological changes are creating many challenges for information systems 
organizations. One of the most pressing of these challenges is responding to and supporting the growing 
number of users who have the technology and who want to provide and to retrieve increasing amounts of 
institutional data for performing business functions and for decision support. An important role for 
information systems organizations is to provide a framework and guidelines that will serve the diverse 
and expanding needs of these sophisticated users. 

Data-the raw material for this new information age-must be formally managed as are other 
institutional resources such as people, finances, and facilities. Data accuracy, consistency, and reliability 
need to be ensured. Data also becomes the key to integrating future systems. The University of 
Michigan University Information Systems (UIS) has proactively adopted a data orientation toward its 
development of systems and its long-term systems planning. UIS established a Data Administration 
function to provide guidelines for some immediate assistance to users and to provide a long-term 
planning approach for integrating data and systems and mapping them to University goals and objectives. 
This paper provides an overview of the establishment of this Data Administration function and its 
components, followed by a more in-depth presentation of the long -term Strategic Data Planning process 
underway. 



Data Administration 

Technological changes affect the way systems are developed and implemented. More users at 
various levels of the organization are now involved in the development and use of new applications 
because technology is driving the distribution of data and processes, and information is being used 
increasingly as a competitive tool. Technology is, in effect, increasing our institution's appetite for data. 
This has resulted in a heightened need to enhance the accessibility, integrity, and usefulness of the 
institutional data and to promote the view of information management oriented to data as an integrated 
University resource rather than one that focuses on separate departmental processes. 

To establish credibility for a data administration function, an institution must recognize the 
problems data administration can solve or the benefits it can provide. At the University of Michigan, it 
was a combination of both that led UIS to create its Data Administration group. 

Specific data-related problems that currently face the University of Michigan, as well as many 
other institutions and corporations, include: 




02/12/93 f 

— 313- 



• Interfaces and extracts which causes timing delays and loss of currency, 

• Redundant data entry, 

• Redundant data which is unplanned and unmanaged, 

• Diminished data integrity, 

• Inflexible systems, 

• Restrictions on information sharing which were unwanted and unplanned, 

• Lack of common, global understanding of information, and 

• Inconsistencies in definition and content of data. 

Benefits of a data administration function to an institution vary depending on the audience. The 
following benefits are separated into four categories: 

• General audience: 

• Maximize or reengineer business processes by reusing data, 

• Result in flexible systems since systems are based on an institution-wide data model, 

• Result in maintainable systems, and, 

• Promote controlled redundancy. 

• Information Systems management and staff: 

• Reduce politics in projects (common definition of business from a data perspective), 

• Escape from the maintenance quagmire, and 

• Establish data as a foundation (data tends to be more stable than procedures). 

• Middle management: 

• Enable sharing of data, 

• Reduce political ban iers, and 

• Eliminate technology-related business difficulties within daily work routine. 

• Executive management: 

• Achieve competitive advantage, 

• Maintain and promote growth, 

• Support better product or service offerings, and 

• Improve quality. 

Dgitfl Administration at the University of Michigan 

Many factors contributed to motivating the University of Michigan to establish a data 
administration function: the strategic decision to establish a data orientation for information systems, the 
anticipation of distributed computing environments, the development of systems in relational database 
format, and especially, recognition by our users of the importance of data integrity and consistency 
during our Data Access Project. The Data Access Project 1 was created to improve end-user access to 
institutional data. The first report from the Data Access Project recommended "establishing a Data 
Administration function." The report stated that this function was critical to the success of making 
institutional data more readily available. The report also stated that data must be managed across all 
institutional systems to ensure consistency and common definitions, that Data Administration must 
develop effective liaisons and communications with user groups, that Data Administration must develop 
an institutional data model, and that Data Administration must develop a standard format for data 
dictionaries. This report from the Data Access Project, the first to focus solely on data access, 
summarized the problems with accessing data and made specific recommendations on how to address 
some of the problems. 



Bennett, Peggy. Improving Access to Corpo r ate Data: Users Remain Partners in Ex perimentation, 
(CUMREC Proceedings, 1992) 
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The Data Administration group was established within University Information Systems in 
November 1990 and has grown to include three data analysts, an administrative systems/data planner, and 
a support person. 

Every day, a wide variety of data is collected and used to conduct the activities of the 
University. The philosophy adopted by the University is that data is institutionally more valuable when it 
is widely and appropriately used. Its value is diminished when it is misused, misinterpreted, or not 
accessible by people who have a legitimate use for it. This philosophy set the stage for the work of the 
Data Administration group and contributed to its mission and goals which follow. 



Mission; 

Data Administration will promote data as any valuable shared resource by creating a data environment 
for the University of Michigan which will ensure the establishment, maintenance, and delivery of 
accurate and reliable institutional data. 

• Recognize and promote the importance of data as a valuable institutional resource. 

• F^omote data consistency and standardization throughout the University. 

• Create a data architecture that supports the informational needs and business functions of the 
University. 

• Minimize duplication in capturing, storing, and maintaining data. 

• Encourage and facilitate data access and data sharing. 

• Improve the quality, accuracy, and integrity of institutional data resources. 

• Improve data management and access through the use of appropriate methods, tools, and 
techniques. 

• Promote the use of the data resource in support of University decision making and strategic 
planning. 



Data is a resource and should be managed as a resource. Managing any resource includes 
addressing the following life cycle stages: 

1 . Plan for the resource. 

2. Acquire or create the resource. 

3. Maintain the resource. 

4. Use or exploit the resource. 

5. Dispose of the resource. 

The Data Administration group in University Information Systems (UIS) is developing and 
applying a set of formal rules and methods to manage the University's data resources and maximize their 
value. Data Administration is concerned with those data resources that arc critical to the administrative 
functions of the University, regardless of whether the data is used or maintained by administrative, 
academic, or Hospital clinical/patient care units. 

Although administrative data may be stored in different database management systems and in 
different physical locations, all of it can be thought of as forming a single "logical" database, called the 
"institutional database." This terminology does not mean that information should reside in a single 
physical database. It means that no matter where the data is, the same principles of data management 
should apply to maintain the value of the data and ensure that it is used effectively. 

If a data element satisfies one or more of the following criteria, it is considered institutional data 
at the University and therefore, part of the institutional database: 
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• A University administrative or academic unit needs it for an administrative or clerical function- 
functions such as planning, managing, operating, controlling, or auditing. 

• It is generated as a result of clinical or patient care activities. 

• It is generally used by more than one organizational unit. (Data elements used by a single 
department or office typically are not considered part of the University's institutional database.) 

• It is included in an official University administrative report. 

• It is used to derive another data element that meets any of the other three criteria in this list. 

Data Administration at the University of Michigan includes four essential aspects of managing 
this institutional data: data planning, data standards, systems development support, and data accessibility. 

Data Planning 

Managing data resources with an eye to the future requires the definition of a data architecture 
and a systematic way of planning database applications and systems. Both are underway at the 
University. Planning is needed to provide a framework in which administrators can objectively 
determine the scope of each project, decide which projects should be initiated, and determine the order 
in which they should be developed. Strategic data planning, which is described in more detail later in the 
paper, is the method the University of Michigan is using to plan for its long-term data and system needs. 

A critical component of data planning is a policy and a set of guidelines for managing data 
resources. The policies and guidelines governing data administration arc explained in two documents, 
institutional Data Resource Management Policy and Data Administration Guidelines for Institutional 
Data Resources. These documents were prepared by an ITD/user group building on example documents 
from both industry and higher education institutions, such as Virginia Tech and Indiana University. Input 
and revisions to these documents were solicited from major committees and/or individuals in all 
school/coilege/administrativc units on campus. They have been extremely well received and supported. 

On an ongoing basis, Data Administration is responsible for: 

• Developing effective liaison and communication with the people who use the data. 

• Reconciling conflicts in data definitions. 

• Dealing with issues of data ownership, data redundancy, data integrity and accuracy, and data usage. 

• Data migration strategics. 




For projects involving U1S, a University-customized Systems Development Methodology 
(SDM) is used to guide the systems development effort. Tasks related to Data Administration are defined 
in the SDM and include: 

• Assisting with project estimates. 

• Assisting in new data requirement definition. 

• Building a logical model of the data (data modeling is generally considered the most visible service 
provided by Data Administration). 

• Reviews data for use of institutional naming standards for entities and attributes. 

• Assists in assigning sensitivity levels to data resources. 

• Mapping requirements against vendor models. 

• Working with the database administrator on physical database design. 

Data Administration services in support of systems development are also available to projects 
outside of UIS and have been used by developers of departmental systems at UM. 
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Before a database system is built, the content and structure of the data must be known. Data 
modeling includes creating and validating a logical data model to collect data requirements prior to 
building a database system. A data model is an abstract representation of the structure and content of a 
set of data, independent of any database management system. 

To be successful, data modeling requires carefully selecting the designers and system users who 
will participate in the data modeling session. A data analyst, from Data Administration, trained in data 
modeling techniques, leads the group through a series of questions and discussions. These data-modeling 
sessions can last from a few hours to many days. The goal is to create a model with the simplest 
structure, a structure with the least amount of redundancy. Rather than displaying data relationships built 
for a specific application, a good model discloses the general nature of the data, allowing for future 
growth and expansion. 

Eventually, Data Administration will consolidate the data models from numerous projects 
(bottom-up) and the strategic data planning (top-down) to create an institution- wide data model. This 
model will serve as a map of the institutional data, allowing the University to build new systems that can 
share accurate and timely data. 

Data Standards 

Data users face a critical need to merge and analyze data from various administrative 
information systems to make informed decisions. One way to facilitate this process is through the use of 
data standards. Data standards comprise the rules for defining, documenting, and naming data. At the 
University of Michigan, standards are evolving and currently consist of various kinds of 
recommendations and approved lists, including: guidelines for defining data elements, major 
classifications of data, standard syntax for naming data, suggested formats for data r approved 
abbreviations, and guidelines for using and enforcing standards. These were developed in conjunction 
with data users. 

Since institutional data needs to be identified on a University-wide basis, the standards for 
naming and defining data make data sharing easier and eliminate unintentional redundancy. After data 
has been identified in data modeling, it is named and defined according to the standards. 



ITD has begun investigating data-repository software that will store information about U-M 
institutional data and how it is used. The ideal repository would automate the tasks of searching for data 
elements and comparing them to one another. The repository would provide a data directory that allows 
users to search the repository for data elements and identify their physical locations. 

Data Administration's goal is to help authorized University users easily access data in the 
institutional database. Members of the Data Access Project recommended the establishment of a Data 
Administration group to manage data across all institutional systems to provide consistency and 
integration. The Data Administration group has been intimately involved in data modeling efforts of the 
projects as well as with issues of data definition reconciliation, data ownership, data redundancy, data 
integrity, accuracy, and data usage. 
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STRATEGIC DATA PLANNING 

Definition and Purpose 

Strategic data planning means establishing a long-term direction for effectively using 
information resources to support an institution's goals and objectives. As the University of Michigan 
continues to review its investment in and reliance on information technology, it has implemented 
"strategic data planning" to build an institution-wide data model and to create an administrative 
information systems plan that supports University goals and objectives. 

The term "strategic data planning" is something of a misnomer. While such planning strongly 
emphasizes defining data requirements, it gives equal attention to how the University functions. Strategic 
data planning stresses looking at how the University functions rather than how it is currently organized. 
It is concerned with what the University wants to accomplish in the future, rather than who is or should 
be doing it, or how it will be accomplished. Strategic data planning tries to answer the following 
questions: 

• What business are we in? 

• What things must we manage to conduct this business? 

• What data do we require to manage those things? 

With this information, the University can develop an institution-wide data model and make 
objective decisions when determining priorities and allocating fimds and other resources for system 
development activities. 

One of many benefits of strategic data planning is that it increases the value and accessibility of 
the University's data resources. Over time, this should reduce the number of systems and the amount of 
data needed to run the University. Strategic data planning will identify administrative systems that can 
share the same data. In the past, many administrative systems were developed to automate the processes 
within a central administrative unit (sometimes referred to in the industry as "islands of automation"), and 
the data wasn't easily accessible to those outside the central unit. As a result, many departments had to 
develop local systems to supplement the central one, which led to redundant systems and redundant data 
entry across the University. 

The implementation of relational database technology is helping the University overcome this 
problem. Strategic data planning, when coupled with the ability to access distributed data through 
relational technology, will make it easier for users to access and manipulate administrative data to serve 
their particular needs, which should lead to streamlined business processes and procedures. Strategic 
data planning also contributes to institution-wide communication and education about the data and 
functions of the University. 

Responsibility for coordinating and developing the strategic data plan is assigned to the 
Coordinator of Administrative System Planning. This position was established in fall 1991 as a joint 
appointment between the Controller's office and Data Administration. The position reports both to the 
Director of Data Administration, and to the Controller and Director of Financial Operations. At the 
direction of the Vice President and Chief Financial Officer, the Controller and Director of Financial 
Operations has responsibility to oversee planning for administrative systems development for Business 
and Finance and to coordinate those plans with other vice-presidential areas. 
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Methodology 

During 1992, staff from many groups and departments on the administrative and academic sides 
of the University attended meetings where they learned about the University's intention to develop an 
institution-wide strategic data plan. Staff had a chance to ask questions and to provide their input to the 
planning process. Presentations at these meetings outlined the steps involved in strategic data planning, 
which include: 

1. Planning the Plan 

This step took most of one year to accomplish (about ,5 FTE) and some activities still need to be 
addressed. The planning step includes setting the scope of the initial effort, communicating with those 
included in the scope to promote the effort and to identify participants, training for the Coordinator of 
Administrative Systems Planning and support staff, designing a methodology, purchasing a Computer 
Aided Software Engineering (CASE) tool to support the methodology, and preparing a schedule of the 
order in which functions within the scope of the effort will be addressed. 

With input from the Vice President and Chief Financial Officer and others, the initial scope of 
strategic data planning was set in this step to include the administrative functions that fall primarily 
within Business and Finance and Academic Affairs, Other areas of the University will be added in later 
phases. Units need to define each function for which they have primary responsibility; one person from 
each unit will lead the effort to define the functions that are the primary responsibility of the unit. Other 
participants will include staff and faculty administrators who have some role and responsibility in the 
function being defined. 

Another part of the planning phase is developing a methodology (that is, customized procedures 
and techniques for implementing the plan). The methodology developed at the University of Michigan is 
based on the Information Strategy Planning phase of the Information Engineering methodology 
popularized by James Martin. Because the strategic data planning effort requires working with massive 
amounts of information that are too unwieldy to handle manually, a CASE tool is being used to help 
collect information and analyze the models that are to be defined. The Planning Tool from 
KnowledgeWarc, Inc. was selected to support the strategic data planning effort. 

2. Defining Goals and Problems 

// we don't change our direction, we might end up where we are headed - Chinese proverb 

Administrative systems must be designed to meet the long-term goals of the University as well 
as resolve existing, ongoing problems. In addition to just being a good idea in general, a shared set of 
goals and problems will help provide direction to the strategic planning effort. Initially, strategic 
planners must work with representatives to identify and forecast the goals and problems that will have a 
University-wide impact during the next five years. A variety of methods will be used to collect goals and 
problems; Total Quality Management, currently underway at the University, is having a positive impact 
on this step. The results will provide the basis for the next steps-defining the function model and the 
data model. 

3. Defining the Function Model 

A function is a group of processes that supports one aspect of operating the University, 
Procuring goods and services, managing human resources, and admitting students are examples of 
functions. While a function is ongoing and continuous, processes are specific tasks that have a definable 
beginning and end. As shown in the illustration, a function model for the procurement of goods and 
services could include processes such as creating purchase requisitions, maintaining supplier information, 
creating purchase orders, recording invoices, and paying invoices. 



con- 02/12/93 2 o 0 

CI\1L —319 — 



A function model will be defined by working with a group of representatives in facilitated 
meetings. The function model helps the University clarify and communicate what it does independently of 
how it is organized. It also provides a tool to define the data needs of the University. 

4. Defining the Data Model 

Data modeling at this level of planning focuses on defining the major entities and relationships that 
support the functions and processes mentioned in the previous step. This type of data model establishes a 
framework for standardizing, integrating, and planning administrative information systems (see illustration). 
A data model will be defined by working with a group of representatives (usually the same group used to 
define the function model) in facilitated meetings. 

Staff in the Data Administration group will work with users to compare and consolidate these data 
models across functional boundaries to form an institution-wide data model, which will, as part of the data 
architecture, provide the basis for the data planning efforts of the Data Administration group. 

5. Integiating the Function and Data Models: Data Source and Use Analysis 

To integrate the function model and data models, strategic planners must determine the 
relationships between the functions and the data by identifying the data entities that each function creates, 
maintains, or uses (see illustration). The integrated model can then be used to identify strategic projects and 
prioritize them as part of an overall administrative Information Systems Plan. 

There are a variety of analytical techniques that will be used to identify and prioritize projects. 
Affinity analysis is one example of a technique that will be used to identify strategic projects. Affinity is 
defined as a likeness based on a relationship or causal connection. In this step, affinity analysis measures the 
affinity between entities and processes based on the source and use information. This allows the planner to 
cluster processes and data together into a natural business areas (or projects). Another technique, called the 
Northwest rule provides the planner with the proper implementation sequence for the projects. Clustered 
processes that create information should be implemented before processes that update or use information. If 
information is not available in electronic form, it makes little sense to automate a process or set of processes 
to use the information. 

6. Architecture 

In addition to the steps outlined previously, a technology architecture must be defined to indicate 
the hardware, software, and networking environment necessary to support the models. Given the constant 
evolution of technology, this step is difficult to accomplish, and any decisions can be rendered inaccurate or 
obsolete by new developments. At the University, an effort to define this environment for ad hoc reporting 
was just completed. Most of our current mainframe applications reside in IMS systems. The plan for 
enhancing the ad hoc reporting environment calls for this information to be moved into an Oracle RDBMS 
environment running on IBM RS-6000 servers. A separate effort to define a new application architecture 
for operational systems is currently underway. 
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Simplified Examples of a Function Model, a Data Model, and an Integrated Model 



Purchasing 

Create requisition for purchase 
Maintain supplier information 
Create purchase orders 
Record invoice from supplier 

Recor d supplier performance data 

Analyze supplier performance 

Pay tupplier 

Function model in which Purchasing is the function and the 
subordinate items are processes. 



Functions 


Data 


Accounts 
Payable 


Invoice 


Requisition 


Purchase 
Order 


Supplier 


Create requisition for purchase 






C 






Maintain supplier information 


R 


R 




R 


CRUD 


Create purchase orders 






R 


C 


R 


Record invoice from supplier 


C 


R 




R 


R 


Record supplier performance data 


R 


R 






CU 


Analyze supplier performance 


R 


R 




R 


R 


Pay supplier 


RU 


RU 






R 



Note: C a create, R « read* U « update, D « delete 
Integrated model reflecting the integration of the fraction and data moddx. 



Not*: Tbeae example* are not organization-specific; they do not necessarily represent the purchasing function at the University of Michigan. 



Requisition 







Purchase 
Oder 




Invoice 




Accounts 




Payable 



Date a a ad al inriiraring r ri atio n a hip a between entities. Attributes are not 
shown at tfat Strategic Data Planning level fa Requisition, attibutes 
might include item nnmber, description, quantity, unit price, total, and 



7. Preparing an Information Systems Plan 

Staff in University units and the Data Administration group will analyze the functions and data 
entities and identify the units that are responsible for them or use them in support of their mission. Also, 
IMS staff and users will inventory and evaluate current systems-including systems developed and housed 
on the administrative computing mainframe and local systems developed by individual uiiits-to 
determine how well they support the defined models. The Information Systems Plan will be based on the 
results of the analysis of this information and the integrated model. The Information Systems Plan will 
provide objective planning information to those making funding decisions and prioritizing systems 
development efforts. More detailed systems project work can take place based on the models once the 
appropriate priority and funding decisions are made. 

The intent is to update the Information Systems Plan annually and incorporate it as an integral 
part of the University's strategic planning process. A plan that is not updated periodically to reflect 
changes in goals and objectives will quickly lose its significance. 
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Selling the Approach to Management 

While leadership from Data Administration is critical to the success of strategic data planning, 
there must be a champion at the executive level for it to be successful. With competing priorities and 
demands for time, strategic planning of any sort can lose its focus and momentum without constant 
support. Since the Vice President and Chief Financial Officer wanted to see a plan for administrative 
systems and is interested in making information more available, selling strategic data planning was fairly 
straight-forward in the Business and Finance division. It was much more difficult in the Academic 
Affairs arena where leadership changes were taking place at the same time we were trying to get this 
division on board. A number of months were lost because of the leadership changes. In retrospect, we 
should have moved forward on the functions in the Business and Finance area that have minimal direct 
impact on Academic Affairs functions without waiting for the Academic Affairs endorsement. Valuable 
momentum was lost; changes in management and delays are among the major pitfalls of a strategic data 
planning process. 

Selling the approach to lower level management is equally important. These are the individuals 
primarily responsible for the functions we are trying to define. By definition, staff at these levels of 
management are inherently more narrowly focused than people at the executive level. Some find it 
difficult to achieve and maintain a broad vision of the institution from a systems and data perspective, 
and therefore, they have trouble understanding the need for and benefits of strategic data planning. 
Hence the need for support from the executive level. The executive officer can resolve issues, commit 
resources, and set priorities when necessary. Some staff will understand the need and benefits but may 
identify issues that must be addressed in order for data administration and strategic data planning to be 
successful. Documenting these issues and getting executive management to address them contributes to 
the credibility of the effort. In summary, ongoing communication is a key element in selling the 
approach to the institution. 



iptmng the presentations to the units within the initial scope of the strategic data planning effort, several 
issues were identified. 

• Concerns about the impact on budgets and project funding 

Some participants were worried about budget cuts and being asked to do more with the same or 
less funds. Some participants suggested that funding for developing strategic and tactical projects should 
be addressed separately from maintaining and operating current systems. The budget situation at the 
University of Michigan, while not unique, is a sensitive and very real issue. 

Efforts are underway to review how priorities are set and funding is allocated for administrative 
information systems development, maintenance, operation, and access. It is expected that these efforts 
will address most budget concerns to some degree. The approach must strike a balance between 
strategic, tactical, and operational decision-making, control, and funding by departments and central 
units. Hie Strategic Data Planning effort is intentionally separate from an individual unit's budget 
process and is meant to be a tool for those individuals and groups making decisions about administrative 
information systems. 
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. Concerns about the impact on current projects, unit-specific enhancements, or mandated changes to 
operational systems . .. 

Mandated changes will continue to be a reality and must be addressed on a timely basis. Until 
the first Information Systems Plan is complete, it would be difficult to understand the impact on current 
development projects. Extensive, ongoing development that does not adhere to an overall architecture 
can negatively impact a strategic data planning effort, in one recent case, we were able to convince 
people who were working on several related projects to reconcile their data models by participating in the 
creation of a high-level data modeling effort. Another way to address this is to encourage 
communication and cooperation among projects. Units should ask themselves what other units might be 
affected by any proposed system changes and include those units in the project planning process. The 
Coordinator of Administrative Systems Planning is working with others to facilitate this process. 

• Questions about the amount of effort required by units 

Many units were concerned about the amount of time they would be required to invest m this 
effort Units will need to be involved in every step of the Strategic Data Planning methodology; Uujus 
..Limply a hnsinc** pi™ rather than a technology Plan . One of the major pitfalls of a strategic data 
planning effort is not involving the right individuals. If someone is not involved, that individual may not 
be supportive of the results. 

The amount of lime required will depend on the size and complexity of the functional area being 
defined A six to eight week duration for each function is considered reasonable. In addition, units and 
technical staff will be asked to inventory the current systems. A tentative schedule, based on functional 
areas and identifying potential participants, will be published for review. During the planning stage for 
each functional area, a project plan providing detailed estimates of the necessary resources will be 
prepared. 

• Need for total involvement and cooperation from all units within the scope of the effort 

Most units believed that this planning effort would be successful only if all of the units within 
the scope of the effort participate in the process. Some units believed that the models must be used by 
management to make decisions about future administrative information systems development projects for 
Strategic Data Planning to be considered successful. 

Participants with an opinion felt strongly that Academic Affairs should be included in 
determining the initial scope of the effort, as the Vice President and Chief Financial Officer originally 
suggested Many Business and Finance functions are tightly linked with Academic Affairs. As was 
mentioned earlier, efforts to include Academic Affairs units took significantly longer than efforts to 
include Business and Finance. Other participants from outside of Academic Affairs and Business and 
Finance are identified and invited to participate on an as-needed basis. 

The following recommendations were documented and communicated to management in 
response to the previously listed issues: 

• Address project funding and budget issues. . 

. In the interim prior to the completion of the Strategic Data Planning effort, focus on communication, 

coordination, and "customers" with all current administrative systems projects. 
. Produce a schedule, identifying sequence and participants, for the Strategic Data Planning effort. 
. Ensure commitment from all parties within the initial scope of the Strategic Data Planning effort. 
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• Other Issues 

There are three other "pitfalls" to be aware of that didn't necessarily come up in the presentations 
to staff. Many times, strategic data planning identifies a need to reorganize. The integrated function and 
data models produce "natural business areas" that may be different that the current organizational 
structure. While this doesn't mean an institution must reorganize, it does make management aware of the 
possibility. 

"The art of progress is to preserve order amid change and to preserve change amid order" (Alfred North 
Whitehead , philosopher and mathematician ) 

The second pitfall is migration. Migration is a critical implementation component of strategic 
data planning and it is essential that the methodology and resulting Information Systems Plan produce a 
realistic migration plan. 

The last pitfall is a fear or lack of understanding of a data-driven methodology. Strategic data 
planning is a new approach to many people. Some find it difficult to make the transition from more 
traditional planning and development methodologies. Continuing education and communication directed 
at this issue is important to the overall success of strategic data planning. 

.Current Status and Expwfcnm 

As of this writing, strategic data planning is underway in two areas and plans are being made for 
other areas. One area is the function "procure goods and services" and is being accomplished as part of a 
Total Quality Management Quality Improvement Team's (QIT) efforts. The QIT had already defined its 
goals and problems. The Coordinator of Administrative Systems Planning came in at this point, at the 
group's request, to create a strategic data plan based on those goals and problems. This effort is not yet 
complete. Another area is student-related information. Several student-related projects were in progress, 
and a discussion on strategic data planning disclosed a need to define a high-level data model to guide the 
individual projects. Plans are also being made to do strategic data planning for the personnel and finance 
areas. After discussions with executive management, a schedule will be prepared for the rest of the 
functions within Business and Finance and Academic Affairs. 

Those involved in strategic data planning will quickly learn the value of flexibility. While 
having a methodology is important, it is equally important to know how to get results using many 
different techniques and in different sequences. Each group's situation is unique. It is the responsibility 
of the strategic data planning coordinator to recognize the needs of the group and adjust accordingly. 
Obviously one will get better at this with experience and training. An approach to this problem is to 
contract with a consultant with experience in this type of planning. Much of the research indicates that 
you should not attempt strategic data planning the first time without a consultant. (Of course, the 
consultants write most of the articles and hold the seminars where you obtain this information.) We 
decided to move forward on our own for political and monetary reasons. We did, however, pilot the 
methodology on a low-risk , low-visibility project prior to trying it for "real." 

Some consultants indicate that it takes up to five iterations to get a solid plan in place. Given 
the fact that we expect to update the plan on an annual basis, we expect it to take up to five years to have 
a complete, detailed strategic data plan. We do expect interim results given that we intend to make 
decisions based on the results of this plan in the budget process for 1994-95. A iack of interim results is 
another common pitfall that we want to avoid. 
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SUMMARY 

"The more people realize that strategic planning can be quite real in its consequence, the more seriously 
they will take it." (Bryson, 1988) 

Rapid technology changes are creating many challenges for information systems organizations 
and, at the same time, providing new opportunities to information systems users. The increased need for 
access to institutional data is driving the need to manage the institution's data resources more than ever. 
The University of Michigan is meeting this challenge by establishing a Data Administration to ensure the 
accuracy, integrity, reliability and accessibility of the data resource. 

As the University's investment in information technology continues to climb, it stands to reason 
that the University should incoiporate information technology in its decision-making equation and focus 
its investment on those projects that contribute directly to the goals and objectives of the University. 
Data Administration and the strategic data planning effort are key factors in developing a plan to meet 
these goals and objectives. 
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Moving Toward a Campus-Wide Information System: 
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Dr. Alan Hargravc 
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PO Box 97268 
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Much is said these days about Total Quality Management. The basic theme 
behind TQM is that the customer demands a quality product at the lowest possible cost. 
More than just a "the customer is always right" approach, TQM focuses on producing a 
quality product from the start rather than just correcting mistakes. It is a management 
philosophy that recognizes the importance of the customer's right to choose another 
producer if they are not pleased. The fact that there are many producers of a particular 
product increases the customer's ability to choose. The result is that products arc driven 
by the consumers rather than by the producers. 

Colleges and universities traditionally represent a producer driven economy. Our 
customers, the students, are held at our mercy with regard to the quality of the product, 
their education. However, with increased emphasis on accountability, we are moving 
toward a consumer driven economy where the students increasingly demand quality in all 
areas of their academic experience. This goes beyond the classroom to include all areas of 
their interaction with the university. How simple (or difficult) it is to register tor classes 
or to use the library are just as important to the perception of quality as is the instructional 
experience itself. This is where a campus-wide information system (CWIS) can play an 
important role in improving the quality of the product we produce. 

Campus-Wide Information Systems 

Just what is a CWIS? Ideally it is all things to all people. Anytime one needs 
information ranging from today's news or weather to the class list for next semester, the 
CWIS should be the first place consulted. Technology has provided an exceptional 
opportunity to deliver information directly to the customer. The problem with many 
technology solutions today is that much of the information the students desire is not 
directly available to them. For example, it is not unreasonable for a student to want to 
view a current copy of his/her transcript. However, it is still the exception rather than the 
rule that this is directly available in any form without a trip to the academic records 
office. This is true even though the transcript is probably maintained in machine readable 
form on a computer. 

For a CWIS to solve the problems of information delivery to the university 
community, it must meet three important criteria. The first of these is accessibility. The 
ideal CWIS can be reached anytime from any location. In practice, the CWIS should be 
available 24 hours a day from any kind of computer workstation, both on and off campus. 
Other technologies such as the telephone should serve as access points when the type of 
information makes it reasonable. Even though it is impossible to implement this ideal 



level of accessibility, any CWIS that does not aspire to this goal may be limited in its 
success. 

The second criterion for a successful CWIS is usability. The system must be easy 
to use and it must be easy to find the desired information. These arc not necessarily the 
same. Elaborate menus may make a system easy to use but if a person cannot find the 
desired information they arc of little value. Training in the use of a CWIS should be 
avoided if at all possible. In other words, it should not require a high level of expertise lo 
successfully use a good CWIS. 

Finally, and probably most importantly, a good CWIS must provide the 
information that people want to see. This information can be divided into two categories: 
general interest and specialized. General interest information such as today's weather, the 
daily calendar of events and the menu at the student cafeteria is what will attract people to 
the system and make them regular users. Specialized information is that which has a very 
limited audience either by the nature of the information or needed restrictions on its 
access. For example, a student's transcript is certainly specialized information in that it 
should only be accessible by the student or appropriate university staff. 

Many current CWIS implementations do an excellent job of providing general 
interest information but do not go on to provide specialized information. The transcript 
example cited above would not even be considered as a part of the CWIS. While there arc 
good reasons not to burden a general interest system with specialized information, the 
former can provide simple links to the latter. For example, one feature of the CWIS might 
be to call the transcript program. The transcript program need not be part of the CWIS per 
se but could actually be a totally different system with its own security, etc. A major 
advantage to such an approach is that the CWIS becomes the single point of access for a 
wide variety of information. 

Providing a general interest CWIS is relatively easy since several public domain 
implementations are readily available. One simply installs software or a server and 
provides document files that contain the information. Access software is then installed on 
client workstations so that the information can be viewed. Depending on the particular 
implementation chosen, software is available for a wide variety of both server and client 
platforms. 

One difficulty lies in providing the specialized information that can be a part of, 
or accessible from, a truly global CWIS. Much of this information already exists in 
computerized form on many campuses. The problem is that most of it is "locked up" in 
production systems and inaccessible to the average user (student or faculty). How then do 
we provide an information rich environment within the context of an existing investment 
in information technoiugy? 

The Existing Investment in Information Technology 

The volume of information that must be processed to run a university requires that 
automated systems be employed. Most campuses have invested heavily in systems to 
handle areas such as registration and enrollment, student billing and financial 
management. Whether these systems were locally assembled or purchased, one thing that, 
most have in common is that they were developed to automate existing tasks. While these 



automated systems may help process large amounts of information, they do not always 
lead to a higher quality product for the student. 

In order to improve the quality of our information systems and move toward a 
CWIS, we must first look at the types of people who use the information they contain. 
There are two basic types of information users: 1) the production user and 2) the casual 
user. The production user is represented by the university staff member whose job 
involves a high level of interaction with the information system and requires a high level 
of efficiency out of it. In contrast, the casual user may not need the information on a 
regular basis and tends to be less concerned with efficiency in the same sense as the 
production user. This person* s concern is "can I get the information I want and how easy 
is it to obtain?" 

The problem with many current information systems is that they were written 
with the production user in mind. This is not to say that they were poorly designed or that 
they have not benefited the campus. Certain tasks can and should be automated. 
However, by designing for the production user, the casual user is often not considered. 
This means that the casual user (for example a student wishing to confirm their address) 
cannot directly benefit from the system. Hence this person, our customer, does not 
perceive any benefit from the system. 

How then do we provide information to the casual user? Few campuses can afford 
to completely re- write (or re-purchase) all of their information systems just to satisfy this 
need. Even if purchasing a new system is an option, most commercially available systems 
arc only now beginning to recognize the need and begin development in that direction. 
Therefore, we must find ways to provide information directly to our students in a way 
that takes advantage of existing systems. In other words, we must leverage our current 
investment to maximize its benefit. At the same time, new systems must be designed with 
the person who cares most about the information (the student) in mind. 

Many campuses deal with providing information to an audience outside that of the 
production user by providing alternative access methodologies. For example, user- 
friendly front-ends are often developed so that ad-hoc queries can be performed against 
production data. In the past, this was often a difficult approach. However, now there are a 
variety of tools available that make this a very reasonable approach. It is this approach 
that has been taken by Baylor and is described below. 

The Baylor Information System 

It was stated earlier that a CWIS is ideally all things to all people. Designing such 
a system is in reality an impossible task. The fact that this task seems so daunting has 
probably kept many from even attempting it. However, a much more reasonable approach 
is to select individual systems and design an interface for the casual user one system at a 
time. These smaller systems can then be integrated together under some kind of umbrella 
system and before you know it you have a CWIS. The Baylor Information System (BIS) 
is such an umbrella system that is composed of many elements. 

The goal of the BIS is to provide first-hand (i.e., direct) access to desired 
information in a manner that is easy for the casual user of the information. The latter part 
of this goal is particularly important in that most of the development effort is spent there. 
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Much of the information provided under the BIS is available first-hand from the 
production systems used to manage it. However, access through these systems is geared 
toward the production user and this often presents a significant hurdle for the casual user. 
Also, the production systems often lack the kind of security needed for general access. 
For example, the transcript module of our student system does not have the ability to 
restrict who has access to which student's transcript. The only control is over who has 
access to the module as a whole. Properly designed front-ends can overcome these 
limitations in the production application. 

Before describing the BIS, a description of the environment at Baylor is in order. 
Baylor University is a medium-sized liberal arts institution with an enrollment of about 
12,000 students served by 1,500 faculty and staff. The desktop environment consists of 
over 1,200 Macintosh and 400 PC (or clone) workstations. Most of these are connected to 
the campus AppleTalk/Ethernet network. This network provides access to file and print 
services as well as access to various host computers and the Internet. Production systems 
in use include the Student Information System (SIS) from Information Associates, a 
locally developed Human Resources System (HRS), the College and University Financial 
System (CUFS) from AMS and the multiLIS library system from Sobeco. The SIS and 
CUFS systems are run on an IBM 4381, HRS is run on a Honeywell DPS 8/49 and 
multiLIS is run on a VAXcluster. Leveraging these production systems into P^S involved 
several principles which will be described below along with examples of their 
application. 

Principle One: Carefully Select the Target Workstation 

There are two common approaches taken here. One alternative is to select a 
lowest common denominator approach. This approach is often necessary when a wide 
variety of client workstations exists on campus. It often means designing non-graphic, 
character-based systems that sometimes use the client workstation as a simple terminal. 
This can limit the ease of use for the client as well as limit the information display 
capabilities. The second alternative is to select a particular workstation and concentrate 
efforts in that direction. In Baylor's case, the large number of Macintoshes on campus led 
us to select it as our primary workstation. Also, the "point and click" style graphical 
nature of the Macintosh lends itself well to the casual user for which the BIS is designed. 
Even with this choice, there was still an element of the lowest common denominator 
approach in that most of the Macintoshes on campus are low end models (Plus, SE or 
Classic) for which performance is a concern. Limiting our efforts to one client allowed us 
to bring a much higher level of functionality to that platform than would have been 
possible with multiple platforms. 

Principle Two: Adopt a Tools Based Approach 

Take advantage of existing tools so that development does not have to start from 
scratch. In particular, a wide variety of what are called "information harvesting" tools is 
readily available. Some of these tools serve as the foundation for application development 
while others can be used directly. For example, the BIS makes extensive use of Data 
Access Language (DAL) to access data residing in Rdb databases on the VAXcluster. 
DAL is a standard protocol for accessing data in relational databases and it forms the 
foundation for some of our programmed applications. On the other hand, DAL extensions 
built into programs such as Microsoft Excel allow them to be used directly to access host 
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based data. We are now in the process of developing a new application that takes 
advantage of this functionality. 

A corollary to this principle is to try every tool that you can get your hands on. 
The BIS relies on information from a variety of sources and no single tool works well 
with all of these sources. Also, different tools have different strengths when it comes to 
issues such as security and presentation capabilities. While it is important to try various 
tools, it is not advisable to use too diverse a group of them in the actual CWIS. 
Maintenance and support of the applications developed then becomes a problem. Pick the 
tools that work well with your existing production systems and stick with them. 

Principle Three: Deliver Prototypes 

Many components of the BIS were developed as prototypes that were delivered to 
key individuals for testing and feedback. The importance of this principle cannot be 
overstated. Prototyping generally avoids a long system design phase in favor of rapidly 
assembling a working model for an application. The prototype can then be placed into the 
hands of potential users and the design refined as they provide feedback as to whether or 
not the application meets their needs and is easy to use. For example, the front end to the 
financial system was placed into the hands of a few department chairs who routinely had 
need of the information provided, They provided valuable insight into what was really 
needed out of this component of the BIS. 

Principle Four: Don't Just Emulate the Production System 

It usually turns out that the casual user is only interested in key functions so 
enable them without wasting time trying deliver an interface to the whole system. 
Additional functionality may be added later if it is really needed. Also, take advantage of 
the opportunity to add value to the information in the production system. For example, 
there is a particular piece of information in our production financial system that is stored 
as a two-letter code. The BIS front-end to that system takes care of translating that code 
into a meaningful phrase for the user. 

Principle Five: Be Willing to Create Derivative Information 

Some production systems simply do not provide the needed information by 
themselves or adequate information harvesting tools do not exist. In these cases, one must 
be willing to create derivative products that bring together the necessaiy information in a 
manner that is accessible. Derivative information sources violate conventional wisdom 
that there should be a single source of a particular piece of information. However, with 
proper procedures for automatically updating the derivative information, most problems 
can be overcome. The student advisement (transcript) module of the BIS is a good 
example of a derivative information source. The transcript module of the production 
student information system does not store transcripts but creates them on demand by 
collecting the appropriate information on the requested student. Unfortunately, this can be 
a rather slow process. To overcome this, transcripts are created in a batch mode and 
loaded into an Rdb database The student advisement system then retrieves complete 
transcripts from this database in a much more timely manner. 

Another example of a derivative information system included in the BIS is our 
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directory application. The original source for directory information on students is the 
student information system while directory information for employees is stored in the 
human resource system. Information from each of these sources is updated daily into one 
derivative database against which the directory application in the BIS runs. 

Principle Six: Use Existing Systems Where Possible 

Some "production" systems actually are very usable as they are. In the case of the 
BIS, the library card catalog is available directly from the production system. This menu 
driven application is simply called from the BIS main menu. 

Principle Seven; Include a Healthy Dose of General Interest Information 

The emphasis of this paper is toward making use of existing information systems 
as a part of a CWIS. However, most of this information is specialized and only specific 
pieces are of interest to any one individual. By including generous amounts of general 
information in the total CWIS, its utility is increased and people establish the habit of 
consulting it. In Baylor's case, this general interest information is supplied through an 
implementation of Techlnfo from MIT. (Our implementation is known as Bearlnfo after 
the Baylor mascot.) Information contained in Bearlnfo includes the university calendar of 
events, the microcomputer store price list and the class list for the current and the next 
semester. The class list includes enrollment totals so that students can easily check for 
open and closed classes during our pre-registration process. 

BIS Summary 

How does the Baylor Information System stand up against the three criteria stated 
earlier for a campus-wide information system? Accessibility to the BIS is not universal. 
In its present implementation, full BIS functionality is available only from a Macintosh 
workstation connected locally to the campus network. However, since the majority of the 
workstations on campus are Macintoshes, this has not been a severe limitation. In 
usability, much effort has gone into providing interfaces that are easy to use and focused 
enough in their scope that information is easy to find. In terms of the information that 
people want to see, we have provided interfaces to most of the production systems so that 
more information than ever before is available from an individual's desk top. 

This is not to say that there are not limitations in the BIS. Student access to some 
key modules is still not provided since security and other issues are yet to be fully 
resolved. Some modules are only available during certain hours because of the schedules 
for the production systems on which they depend. Finally, there is still much information 
that is not available through a friendly interface under the BIS. 

Closing Thoughts 

Providing a good CWIS requires a vision for an information rich environment that 
empowers students. While this vision is commonly shared with regard to academic 
information, administrative information is often excluded. While privacy considerations 
require that certain information be regulated, campuses must move from being 
information controllers to information providers. A basic model is that if the information 
is about me, it should be easily accessible by me. Some of this information, such as my 
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address, should even be modifiable by me. Granted, such an openness can result in 
abuses. However, the alternative is a tightly controlled system that is perceived as 
unresponsive to the students who expect it to serve them. Unresponsive systems will be 
labeled as poor quality systems and the students will seek alternatives, possibly by taking 
their "business" elsewhere. 

Security of information that should be private between the university and the 
student will always be an issue and justifiably so. However, we must address this issue 
rather than letting it be an excuse not to provide direct access to information. The banking 
industry provides a good model for this in automated teller machines. Certainly the 
security of an individual's money is a very important issue. However, if banks had spent 
all of their time lamenting potential misuse of ATM cards, we would still not have 
automated tellers. Instead, a means of providing security was implemented through 
personal identification codes and personal banking has been radically changed. 

A common form of information access is through what is referred to as client- 
server computing. While we often think of this in terms of the technology involved, more 
attention needs to be placed on the relationship between the university (the server) and 
the student (the client). The CWIS can be an important mechanism to foster this 
relationship and increase the student's perception of quality. Also, as more information is 
placed directly into the hands of students, there may be traditional production tasks that 
are no longer necessary. This frees personnel to engage in actual service to the students, 
further raising the perception of quality. 

There is obviously a very real cost to providing a CWIS. However, the question to 
ask is not "what will it cost to do it?" but "what will it cost not to do it?" As additional 
emphasis is placed on the quality of the total educational experience, those universities 
without an attention to the customer will be unable to compete. The cost of not having an 
effective CWIS will be measured in decreased customer satisfaction that will lead to an 
inability to attract and retain students. 
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PREAMBLE— ACRONYMS AND 'BUZZWORDS': 

Many 'computer people' can't seem to avoid speaking to 
end-users in cryptic acronyms and industry 'buzzwords' and 
this unfortunate habit is often resented by users of 
technology and systems. The result of too much technical 
terminology is invariably a 'communications gap' between 
systems people and their clients — the systems users. 

In this paper, it is unavoidable to introduce many 
computer acronyms, but I will try to keep the bulk of the 
discussion in simple English. This paper and the conference 
presentation are addressed to end-user managers of computer 
systems- This is not a discussion or debate of the strengths 
and weaknesses of Unix versus Windows 1 

Hundreds of new abbreviated 'words' get created each year 
and become part of the technology vocabulary (Exhibit 1). 
But just as 'perestroika' and 'glastnost' were added to our 
everyday English vocabulary, so do many terms from the 
technology field (eg. hacker, nanosecond, etc.). 

To help advance your technology vocabulary, I have 
included a glossary (Appendix II) of most of the terms and 
acronyms mentioned in this paper. You can use this to 
impress both your computer-literate and illiterate friends, 
and hopefully help bridge the communications gap with your 
systems people. 



OPEN SYSTEMS DEFINED: 

Open Systems is the opposite of 'proprietary' or 
'closed 1 . The leading proprietary environments for the past 
ten years have been IBM's MVS and Digital's VMS operating 
systems. Application software solutions are generally not 
portable between proprietary environments. 

Open Systems are computing environments where the 
hardware and software of different vendors are inter- 
changeable; ie. they adhere to recognized standards for 
information exchange, networking and portability. 

DMR Group's Vice-President of Technology Don Tapscott 
defines open systems as "software environments based on 
standards which are vendor- independent and commonly 
available" . 

Montreal-based DMR Group is one of North America's 
leading systems consultants and is active in establishing 
uniform open systems standards as the primary consultant to 
the Open Systems Foundation (OSF) . 



ERLC 



3/7 

-340- 



OPEN SYSTEMS 
'AN OVERVIEW FOR END-USER MANAGERS 1 

capabilities; 

The most widely desired capabilities of Open Systems are 
interoperability, portability, scalability and availability. 

These capabilities require vendor-independent computing 
components (ie. programming languages , database management 
software, operating systems, user interfaces, network 
management etc.) all working together to deliver cost- 
effective application solutions to end-users. 

Interoperability means the ability to network systems 
from multiple vendors. One example would be the sharing of 
data residing in one database among several applications 
running on different hardware platforms. Another example 
would be a single application obtaining data interactively 
from multiple distributed databases. 

Portability means that application software is readily 
movable from one computer platform/environment to another. 
An example would be the capability of moving a General Ledger 
package from an IBM computer to a Digital or H-P computer. 

Scalability is the ability to migrate an application 
among a range of platform sizes, from PC's up to large 
mainframe-type hardware systems. 

Availability simply means that the application solutions 
are both deliverable and numerous in the marketplace, and not 
captive or dependent upon vendor-specific products. 



COMPONENTS : 

To achieve the desired Open Systems capabilities, there 
is a need to standardize the major components of the 
computing environment. These components are: 

* the user interface 

* the database interface 

* operating system interface 

* the network interface 

Exhibit 2 graphically shows the layers or components of 
the computing environment. Standard interfaces make it 
possible for different computer systems to run application 
software interchangeably (ie. portability) and achieve the 
networking benefits referred to as interoperability. 

A standard user interface enables the user to interact 
with the computer system in the same way regardless of the 
application or type of computer being utilized. The user 
interface, especially a Graphical User Interface or 'GUI', 
seems to achieve a quick learning curve which is largely 
portable from one application to another. 
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THE STANDARDS MORASS: 

The key issue in any discussion of Open Systems can be 
summed up in one word, standards. Although substantial 
progress toward achieving the open systems ideal has been 
made, the efforts are hindered by the reality of multiple 
* standards 1 in competition for market acceptance and industry 
recognition. 

There are two types of computing standards; "de-facto" 
and "industry". Unofficial specifications that are widely 
used in the marketplace can become de-facto standards, and 
specifications that are agreed upon by neutral, public 
organizations are industry standards. 

For example, the Unix operating system is widely viewed 
as being the de-facto standard open operating system. There 
are, however, various versions of Unix which have evolved 
from the earliest version produced in AT&T's Bell Labs over 
twenty years ago. The two most popular versions of Unix 
today are based upon AT&T's (System V) and Berkeley Software 
(BSD) . These are de-facto standards. 

Several standard-setting organizations (IEEE, ANSI, OSF) 
are supporting the development of a true industry standard 
operating system based on the two leading Unix 'flavours'. 
One project receiving considerable attention and support has 
been given the acronym POSIX, standing for Portable Operating 
System Interface. Posix will be the set of interface 
•services' in common with different vendor-specific Unix 
flavours in the marketplace. OSF is also supporting the 
definition of a standard Unix-based operating system called 
OSF/1. 

There are both de-facto and industry standard specifi- 
cations for the user interface element as well. The most 
widely recognized are Microsoft's Windows, IBM's Presentation 
Manager, X Windows, and OSF/Motif. 

Exhibit 3 illustrates the evolution of standards as a 
continuous cycle. Standard-setting organizations and vendors 
are shown on the inside influencing the definition, speci- 
fication and implementation processes. 

The development of formal standards takes time, and 
inevitably user or market needs race ahead of the process, 
creating gaps between defined standards and market needs. As 
vendors fill the gaps with enhancements or extensions, the 
standard both fragments and evolves to its next iteration. 

The fact that standards are not static, but are contin- 
uously evolving means that the Open Systems objective is a 
moving target and an ongoing challenge for decision-makers. 
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OPEN SYSTEMS BUSINESS BENEFITS: 

There are both tangible and intangible business benefits 
associated with Open Systems. Some of the obvious advantages 
include: 

1. Cheaper Hardware: 

Open Systems should deliver hardware cost savings as 
computing power becomes a generic commodity, ending 
vendor dependence (ie. multiple suppliers/competitors of 
essentially the same product) . 

2. Cheaper Software: 

Open Systems means software can be developed across a 
much wider spectrum of computing platforms. The enlarged 
market should increase the supply and volume of 
software sales, resulting in lower prices for packages. 
An Open strategy should result in less specialized 
(expensive) expertise, the utilization of more common 
technical tools, and therefore lower development costs. 

3. Better Solutions: 

The end of single-vendor proprietary environments in the 
corporate setting enables the development of enterprise- 
wide networks and the selection of 'best of breed 1 
components from multiple vendors. 

4 . Responsiveness : 

Data/ information becomes more accessible and sharable 
across previously isolated applications. This is the 
business goal of interoperability (ie. improved retrieval 
time and improved integrity of information) . 

5. Flexibility: 

Open Systems have the advantage of operating from desktop 
platforms to the largest mainframes (ie. scalability) , 
This flexibility allows applications to change over time 
to the evolving requirements of end-users and the entire 
corporation. 

6. Investment Protection: 

Current investments in 'legacy 1 systems can be protected 
and extended by the ability to build upon and incorporate 
open technologies. 
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CURRENT TRENDS: 

The most widely-touted solutions riding the Open Systems 
wave at the moment are Unix, Client-Server Architecture, 
Windows, SQL and Downsizing. 

Unix has already been discussed as the operating system 
which is most 'open 1 to a multiple-vendor environment. Unix 
has rapidly become adequate for most commercial applications, 
addressing concerns of many with IBM mainframe backgrounds 
about system management and security. 

In addition, most independent software developers have 
aggressively jumped onto the Open Systems/Unix band-wagon. 
This is going to mean application software that historically 
has been targeted and priced for the mainframe market will be 
much cheaper and available on a variety of Unix platforms. 

Client-Server architecture is a relatively new design 
concept (not a product) which moves substantial application 
functionality to the end-user 1 s desktop PC. The Client- 
Server approach takes advantage of cheap hardware which in 
many cases already exists on the desk. Only the database 
server hardware must be acquired and this will usually be 
only a fraction of the price of a traditional mainframe or 
minicomputer. 

Microsoft's MS/Windows has been an amazing market success 
story with over 10 million copies of the product sold to PC 
users. Software developers are now ready to provide appli- 
cations to run under Windows and tools to develop Windows- 
based systems. The Windows/GUI environment is viewed by many 
as a prerequisite part of systems built using a client • server 
architecture. 

Probably the number one Open Systems capability users are 
looking for is interoperability; accessing data across 
multiple platforms/application's. Tc achieve this capability 
requires a standard method of interacting between 
applications and databases and the open solution is the SQL 
standard. SQL (Structured Query Language) provides a set of 
application programming interfaces or •calls 1 . Relational 
Database software systems which support the SQL interface 
allow applications to update and query data which is 
physically distributed across a network. 

On top of these technical trends is the movement towards 
downsizing, rightsizing, and re-engineering. Organizations 
that are embracing Open Systems strategies are hoping for 
substantial cost savings as mainframe computer centres are 
transformed into network centres and a handful of $20,000 
processors/servers replace $2 million mainframes. Some 
organizations are striving to completely reinvent or 
re-engineer their information and support systems, and are 
adopting an open strategy as a starting point. 
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SUMMARY: 

A recent report on the open systems market from N.Y. 
based consultants Frost & Sullivan International predicts 
that users will place more emphasis on certification of 
products and conformance testing to ensure adherence to 
industry standards. They predict that sales of open systems 
in the U.S. will rise from $23 billion in 1991 to $81 billion 
in 1996. 

DMR's 1991 study of Open Systems Status in Canada 
describes both an old and new model of computing. The old 
being a proprietary , host-based, rigid, top-down, non- 
integrated, vendor controlled architecture unable to meet 
global, volatile, competitive business needs. 

The new 'Open' model includes: integration through 
network centered architectures, multi-platform applications, 
workstations with graphical user interfaces, cooperative 
processing and client-server applications, and external links 
to clients and suppliers. 

DMR 1 s study also indicated that the greatest barrier to 
the adoption of open systems was the lack of awareness among 
decision-makers of the advantages (and disadvantages) of open 
systems. 

Most large organizations have huge investments in func- 
tioning 'legacy' systems that they want to integrate with 
newer technologies. Adopting an open systems strategy 
doesn't have to mean throwing out existing investments in 
software and training. 

To survive in the marketplace, technology vendors are 
going to embrace 'openness' and provide 'hooks' to 
proprietary applications. If you have chosen your vendor 
alliances wisely or luckily, your current applications can 
quite possibly migrate to open compliance. Corporate 
networking will become the critical factor which ties the 
components together. 

One of the benefits of embracing Open Systems at the 
enterprise or institutional level is greater accessibility of 
data across databases (ie. responsiveness). This entails a 
breakdown of traditional 'fiefdoms' of information which 
traditionally have mapped to the institution's organization 
chart. 

Some managers will resist the 'openness' of the data 
which they have previously thought of as their own. Greater 
accessibility of data means that managers who are custodians 
of a portion of corporate data and responsible for its 
integrity, must be willing to share that data to others with 
the need to access it. 
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APPENDIX I 



STANDARDS ORGANIZATIONS: 



ANSI: (American National Standards Institute) 

IEEE: (The Institute of Electrical and Electronics 
Engineers , an organization commissioned by 
ANSI to define or specify standards) 

In 1985 , IEEE formed a committee to develop 
a portable operating system/application 
interface standard, which came to be known as 
the "POSIX" Committee. 

A series of "POSIX" specifications have been 
issued and continue to be developed. Most 
computer vendors have announced that they will 
develop POSIX-compliant products, achieving a 
truly portable, standard operating environment. 

ISO: (International Standards Organization) 

NIST: (U.S. National Institute of Standards & 
Technology) 

OSP: (The Open Software Foundation, a non-profit, 

industry-supported organization formed in 1988 
to promote a portable applications environment) 

0SF attempts to move industry standards into the 
marketplace as quickly as possible. It is not a 
standard setting organization, but offers 
verification methods and tests to ensure 
compatibility with standards and specifications. 

01: (Unix International) 

X/OPEN: (Founded in Europe in 1984 by five computer 

hardware manufacturers that had systems based on 
the Unix operating system) 

X/Open's mission is to guide and manage the 
process of developing a COMMON APPLICATIONS 
ENVIRONMENT (CAE) . 

X/Open has published a widely accepted 
portability standard called XPG, and has 
endorsed the base operating system interface 
called POSIX (see below) 
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APPENDIX II 

GLOSSARY OF TERMINOLOGY: 

API Application programming interface 
ARPA Advanced Research Projects Agency 



CAE 



Common Application Environment (ref. X/Open) 



DOE Distributed Computing Environment (ref. OSF) 
An integretated set of services such as 
directories, security, and remote procedure calls 
which is independent of networks and operating 
systems. 

DME Distributed Management Environment (ref. OSF) 

A common framework for managing a wide range of 
networked systems. 

XPG X/Open Portability Guide 

GUI Graphical User Interface (see Windows) 



MS/Windows 



A product developed by Microsoft which 
provides the graphical user interface 
similar to Apple Macintosh computers. 
The MS/Windows product operates on 
DOS-based PC's. Microsoft is turning the 
MS/Windows product into a full-fledged 
operating system (Windows/NT) . 



OLTP On Line Transaction Processing 

OSF/1 A portable operating system defined by OSF, 

complying with CAE, and supporting Unix SVID and 
BSD features. 

OSI Open Systems Interconnection (ref. ISO) 



POSIX Portable Operating System Interface 
(ref. IEEE Standard 1003) 



SQL Structured Query Language 

A method of accessing databases which has 
evolved as a de-facto standard. 

TCP/IP Transmission Control Protocol/Internet Protocol 
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L INTRODUCTION 

Networking in the Latter Years of the Information Age. 

It has been a long-standing need of man to communicate. Forget the 
drums, bonfires, semaphores, and flashing mirrors of years gone bye. Today, 
managers rely on phones as the prime instruments for communications. They are 
simple, fast, ubiquitous, and geographically boundless. Yet, depending on which 
statistic you wish to accept, somewhere between 50 and 90 percent of business 
phone calls go unanswered on the first try. This annoyance, plus a general interest 
in reducing paperwork, has caused all sorts of people to be eager to try electronic 
mail (e-mail). Its acceptance is making it second only to the phone as essential 
office equipment. By the way, does it register in our minds that FAXing is 
electronic mail? 

And even today, few people understand all of the technical aspects of 
connecting people electronically, but managers know what they want— "everything 
is connected to everything." 1 Yet, it is one thing for the president to tell us to get 
connected, and quite another to be implemented. So, how do we get our arms 
around these issues? Perhaps, what we need is a quick cram course on e-mail and 
its associated technology. The techie stuff includes such things as local area 
networks (LANs) to hook-up the offices and the software (operating systems and 
protocols) to drive these systems. Thus, we end up with a bit more on our plate, 
but at least a half a dozen topics are critical to our understanding of LANs, 
networking, and data communications. 



Jjohn F. Akers, President of IBM, Communications (Chicago: Time-Life Books, 1986), p. 8. 
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//. NETWORKING 



Some defining— Doing some networking? Whether we call it networking or local 
area networks (LANs), selecting the scheme for your campus is no simple task. 
Today's networking/LAN marketplace is crowded with at least fifty different 
vendors, all claiming that their product is THE one you need. Further confusion 
occurs because there are few standards in networking, de facto or otherwise. 
Nonetheless, you may be sure that the simple, small LAN you install today will 
turn into a large, multifloor, multibuilding, or multicampus network in the not too 
distant future. 

In terms of size, the network will only grow. The multivendor approach 
will likely become more multi. The applications we run across the network will 
continue to vary in diversity. And, the unpredictable usage will be the norm. 

In a formal sense, a network is one or more communications circuits and 
associated equipment that establish connections between nodes (users). 2 
(Unfortunately, you'll have to wait until later in the paper to fully appreciate some 
of the words in this definition.) In terms of the technology that makes a local area 
network, it can be said that a LAN consists of some hardware, software, cabling, 
and connectors. The hardware is typically a PC and some added internal 
electronics. The software comes to us from dozens of vendors that provide a LAN 
operating system and applications software products. The cabling can be twisted 
pairs, coax, and/or fiber. And, connectors— such as interface cards, transceivers, 
and cable connectors— provide the linkages between the nodes and the medium. 

LANs have proven their value in organizations that range in size from small 
offices to far flung university campuses. By definition, most local area networks 
connect users within a single building. Yet, as they become more and more 
popular in an organization, LANs expand to adjacent buildings. And before you 
know it, connections are needed beyond the LAN to a city or metropolitan area 
network (MAN) or even to national and international networks or wide area 
networks (WANs). 

Rational behind LANs— A well-designed LAN can deliver many important 
benefits. First, it allows users to share organizational resources such as databases, 
graphic devices, high-speed laser printers, and mass storage devices. Such sharing 
can increase the use of scarce resources, improve individual productivity, and 
promote efficiency. It might even allow us to place less emphasis on making and 
filing paper copies and, as attitudes change, may even reduce intraoffice 
paperwork. Now, let's get into the details. 



2 Stanford H. Rowe, II, Business Telecommunications . 2nd ed., (New York: Macmillian 
Publishing Company, 1991), p. 365. 
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As networking progressed, it became evident that names would have to be 
given to the different methods of getting all these users wired together. You'll hear 
people refer to these grand designs as network architecture, or the more functional 
title of network topology, or cabling configurations-as some prefer. 

More frequently, people like the phrase wiring topologies, so that will be 
our title for this section. The basic topologies are: bus, ring, and star. However, 
in practice, we find a number of wiring schemes that are mixtures of these basic 
topologies. 

Networks with the bus topology sometimes are called backbone networks 
because they connect each device to a central cable called the backbone. 

IV. MEDIA 

Our LAN's electronic transmissions move over highways of cables. These 
cables are the different media. We usually think of cabling as copper wires, but 
more recently, glass (optical fiber), is gaining popularity as a LAN medium. 

LANs are typically cabled with copper and it comes in many varieties. But, 
one observation at the outset: There is no one best cable for LANs!. As 
suggested earlier, the medium for your campus may be a matter of historical 
consequence or thoughtfully chosen, based on present and long-term requirements 
for data, text, graphics, voice, image, and video. 

Media selection is a very important aspect of LAN development. If you 
choose incorrectly, the LAN may not be able to support future loads or may 
introduce reliability problems. Some of us get "stuck" with an existing cable plant 
that would cost millions to dig-up and replace. This wire that stretches from the 
wiring closet to the end user, or the horizontal wiring, represents about 85 percent 
of the cost of any rewiring program. So, with so much of it already in place for 
the phone system, you can bet that unshielded, twisted-pair copper will remain the 
horizontal medium of choice during the coming years. 



V. NETWORKING STANDARDS 

The Need for Standards-Back in the 1950s there were no rules, let alone 
standards, for data to be communicated. In fact, the need for one computer to talk 
to another computer just did not exist. But, over the years and decades, networks 
and telecommunications systems evolved, people in the business realized that each 
system should continue to be unique and specially developed. 



— 355- 



LAN Standards (The 802 Committee)--Because our LANs tend to spill over 
into national and international networks, several professional organizations have 
initiated efforts to standardize various aspects of networking. The work of the 
Institute of Electrical and Electronics Engineers (IEEE) 802 Committee is the best 
known. for LAN standardization efforts. Since it was founded in 1980, the 802 
Committee has approved a standard family for LANs and established several 
different network access protocols, A few of the more significant ones are 
highlighted below: 

1. 802,3 CSMA/CD and Ethernet 

This standard addresses a variety of CSMA/CD architectures that are 
generally based on Ethernet. One of the early subcommittees, it began with 
IBaseT and is progressively working on other developments: 

IBaseT — The early one is referred to as JBase5, which means 1 
Mbps across a baseband medium with a maximum length of 500 meters. This 
standard encompasses the more commonly known implementation named Starlan 
by AT&T. 

10Base2 — Gaining recent popularity is Thinnet or Cheapernet, or 
a 10 Mbps baseband segment of up to 200 meters. 

lOBaseT — The renaissance of copper twistedpairs has been 
sparked by this standard of 10 Mbps baseband signals. 

2. 802.5 Token Ring 

Token-Ring is IBM's LAN methodology which features a single, baseband 
ring topology. It operates over twisted pairs, but can accommodate more PCs if 
data-grade cabling (coax or fiber) is used. IBM began its token-ring running at a 
speed of 4 Mbps. Today, you can buy either 4 Mbps or 16 Mbps Token-Ring. 
Shielded twisted pair (STP) type cable is the most robust installation and is 
preferred for all new rings. However, many cable manufacturers insist that 
16 Mbps run just fine over unshielded twisted pair (UTP). 

A Standard Interconnection-Internationally, in order to facilitate linking 
systems, a model was developed the International Standards Organization (ISO) 
which, along with several telecommunications vendors and CCITT, that became 
known as open systems interconnection (OSI) reference model Since 1978, work 
has been underway to convert the model into a set of standards by precisely 
defining each part of the layers of the model. The architects of the ISO-OSI model 
had as their primary objective to provide a basis for interconnecting dissimilar 
systems for information interchange. The idea being, if they defined the rules or 
protocols of communication, and if followed, incompatible systems made by 
different manufacturers would be able to "talk" to each other. As open systems 
have risen to the forefront in networking, standards are currently evolving from 
two directions Open Systems Interconnection (OSI) and Internet. 
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The Open Systems Interconnection Model 

CCITT X.200 is the designation for Open Systems Interconnection (OSI) 
which is referred to as the Basic Reference Model for open-systems type of 
networking architecture. Announced in 1978, the OSI model uses a layered 
approach, with each layer representing a component of the total process of 
communicating. One way to view this model is view hardware on the bottom' or 
layer 1 . At the top is software or layer 7. In between are varying amounts of 
each. All of the layers in-between describe the standards that handle the necessary 
elements of control. 

The bottom three layers-Physical Link, Data Link, and Network Control- 
of the OSI model are well-defined. Standards have been written and agreed to. 
The combination of the first three layers is the X.25 standard for data transmission 
used in packet switching networks. As one moves on up the scale of the layers, 
the complexity seems to grow. Many standards are required to address all of these 
areas and the work will go on for years. 

Future Directions-With less than two percent market penetration, OSI's future 
does not appear bright. Adopting certain parts of OSI will provide added value to 
users; and for some even full OSI implementation will be of value. The lower 
layers of the OSI model have provided for better multi-vendor connectivity and 
internetworking. And such standards as X.400~the de facto standard for 
electronic mail-and the emerging X.500 may become THE standard for directory 
services. 



VI LAN ARCHITECTURES 

Ethernet--As discussed earlier, Ethernet, is one of the three oldest architectures- 
token bus, token ring, and Ethernet. The original implementation was with coax 
or thick Ethernet. Today, in addition to shielded "thick" coax, which supports 
devices up to 500 meters, Thinnet or Cheapernet coax is about half the size of 
regular coax. However, it reaches out only about 185 meters. The two sizes of 
coax offer the advantage of using thick coax for a backbone application, with 
"skinny" coax being used as spurs to buildings. Still the dominant LAN 
architecture, Ethernet's growth is directly tied to the price of adapter cards 
(network interface cards) which has run at a 40 percent increase a year for the past 
several years. 

AppleTalk-Second in popularity in campus LAN architecture, AppleTalk is 
increasing in numbers in the workplace. To facilitate this occurrence, Apple builds 
its Macs with internal network interface cards and the software to support what it 
calls AppleTalk. Using either Apple-provided twistedpairs or coax, this unique 
"standard" supports up to 32 Macs or printers at a relatively slow speed of 
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230 Kbps. Designed with a CSMA/CD type of access protocol, its workstations 
can be arranged in a bus or star configuration. Interfaces also exist that allow 
Macs to connect to LANs having IBM PCs or clones. 

Token-Ring-Growing almost as fast as Ethernet, IBM's LAN product is token- 
ring. It dominates market share in the sale of IBM token-ring adapter cards. 
These cards generally conform with IEEE 802.5 using baseband transmission on 
either shielded or unshielded twisted pairs. A network interface card (NIC) is used 
to connect the workstation to the token ring on one end. A multi-station access 
unit (MAU) is used to interconnect 4, 6, or 16 users to the network. 

ARCnet— As mentioned earlier, ARCnet was developed to connect minicomputers. 
It uses a token passing bus or star architecture but does not conform with the 
IEEE 802.4 standard. The reason is simple. It came in to being almost a decade 
before standards were even developed. ARCnet is one of the more popular LANs 
because of its early availability for PC-based LANs, relative low cost, flexibility, 
and well-iecognized de facto standard. 

Starlan-- Starlan has been standardized by the IEEE 802.3 subcommittee under 
the IBaseS standard. Using the CSMA/CD access protocol, it can support an 
unspecified number of nodes on a cable up to 500 meters long. Starlan is an 
AT&T methodology, star-oriented, and provides 1 Mbps speed. One early 
advantage of Starlan is that the scheme uses plain old twisted-pair telephone lines 
that are already in most buildings. Also, it uses the CSMA/CD scheme and 
accepts multiple operating systems to include MS-DOS and UNIX. 

Future Directions— One need not look too far to find evidence of the effect that 
unshielded twisted pairs of copper has had on the LAN marketplace. Recent 
market reports show that over 60 percent of all new Ethernet sales are using UTP 
cable. Imagine, over 6 million Ethernet connections will be made this year. The 
lOBaseT standard has worked its way ahead of Token Ring with price driving the 
buying decision. lOBaseT can be purchased for approximately $275 per port, 
compared to $500 to $700 per port for Token Ring. 3 

FDDI networks operating over copper or Copper Distribute ' Data 
Interface (CDD1) at 100 Mbps are predicted to throw traditional Ethernet and 
Token Ring networks from their current leading market position by 1997. 
Spurring the takeover are faster PCs and resource-hungry applications such as 
imaging and full-motion video. The acceptance of copper versus fiber is a matter 
that it is cheaper, and most people already have lots of copper. At issue is how 
long it will take the American National Standards Institute (ANSI), which has been 



3 Gary A. Howard & Frank X. Mara, "Design a Copper Network for PDS and LANs Using UTP," 
Cabling Business , October 1992, p. 10. 
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working for copper standards since mid- 1990, to provide an ANSI-standard for 
product development. Expect it in 1993. 4 



VII LAN OPERATING SYSTEMS 

The issue in systems management in LANs is that of determining what level 
of service is required/desired. That is, do we need a network for occasional e-mail 
use, or are we dealing with more complex database management processes and 
need tightly coupled overall control because the applications span many 
departments and machines? In either case, we need to meet the range of user 
needs in a cost-effective manner. 

Over the past decade or so of growing complexity in networking, users 
have quietly hoped for network control that doesn't appear to "control." But rest 
assured, the more usage and users, the more control will be needed. A LAN, or 
network operating system (NOS) t provides a certain transparent "manager" of the 
system's resources. 

Novell's NetWare—The dominant leader in the NOS business is Novell's NetWare. 
Novell offers at least seven network operating systems (NOSs), as well as custom 
server hardware on which those NOSs run. Five of these run on IBM/IBM- 
compatible systems, one is for Macintoshes, and one for DEC VAX systems. One 
significant feature of Novell is its system fault tolerance (SFT) that provides an 
environment in which, if certain hardware failures occur, the network does not 
necessarily go down. For almost two years, IBM has been selling "NetWare for 
IBM" which gives users a Big Blue direction for now. 

Banyan Vines— Banyan Vines is recognized for its support for large networks and 
network interconnections, One of the very few to run on Unix-based servers, 
Banyan has a distinct advantage in the market place because many WANs contain 
nodes that run Unix operating systems. Few can match Banyan's multi-user, Unix- 
based machines support. 

IBM's LAN Server & OS/2-Although slow in coming, it appears that IBM 
wants you to do your data communications, multi-tasking, and presentation 
services via its latest versions of IBM's operating system or OS/2. So, mark LAN 
Server "out" and OS/2 as "in." However, IBM versions support only IBM token 
rings, not IEEE standards. An extended OS/2 version has enhanced capabilities 
such as the LAN Server and a communications manager. 

Microsoft's LAN Manager— In 1991, we noted that Microsoft was failing to 
resuscitate LAN Manager. This year it is apparent that the Microsoft emphasis is 

4 Lynda Radoscvich, H FDDI Over Copper Will Shake Down Ethernet," Computerworld . October 
26, 1992, p. 50. 
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on Windows Workgroups and NT, Whether these products will or can take a bite 
out of Novell's huge market share will be based on market acceptance of these new 
products. 

3COM *s 3+ & 3+OPEN-Founded by the inventor of Ethernet, 3Com has been a 
leader in LANs from its very beginning. The latest 3Com offering, IAN Manager, 
runs under Microsoft's OS/2. 3Com's 3+Open is the OS/2-LAN Manager product 
sold directly by 3Com. Microsoft also provides its own version of LAN Manager. 
3+Open goes beyond just supporting Ethernet and handles token ring architecture 
as well. Like Novell, LAN Manager provides fault tolerance via mirrored disk 
drives. And, like Banyan Vines, 3Com has announced a name directory service. 

DECs Pathworks-For years, DEC has offered its own NOS, but competition has 
been stiff. Consequently, Digital has quietly introduced a product called 
Pathworks that walks the fine line between a NOS and DECnet. Pathworks ties 
into high-level services provided by DECnet and builds bridges to other PC- 
focused NOSs such as Novell's NetWare, Banyan's Vines, and 3Com's 3+Open, 

Using client and server software, Pathworks accomplishes this balancing 
act on the client side with PCs, Macs, and ULTRIX users getting basic mail 
application, network transport software, terminal emulation, and VMS application 
si pport. Server software provides users with print, file and mail services and 
support for TCP/IP, DECnet, and OSI. And, the server can be VMS, UNIX, or 
OS/2 based. The Digital strategy with Pathworks is to provide a corporate NOS 
to integrate all popular LAN technology and support all standards. 5 

Future Directions-Have you considered that the lines between general-purpose 
operating systems, such as DOS, Apple's System 7, and OS/2, and network 
operating systems, such as Microsoft's Windows Workgroups, are blurring as each 
acquires attributes of the other? As the number of LAN-connected PCs rises along 
with the network-intrinsic applications, the division between operating systems and 
networking operating systems is becoming less and less. Perhaps, by the year 
2000, we will have merged OS and NOS! 

Vlll PEER-TO-PEER LAN OPERATING SYSTEMS 

Peer-to-peer networking enables users to share files and printers without a 
file server. Products to serve this market have been provided by about a dozen 
vendors for years. For a number of years, LANtastic, 1 ONet, Web, and TOPS 
have been the bread-and-butter lines for peer-to-peer networking. 

Apple's System 7 was the first major vendor to make peer networking 
capabilities inherent in an operating system. Novell recently jumped into the peer 



5 Kimbcrly Patch, "Digital's New Path for Pathworks," Datamation , June 1, 1992, pp. 73-76. 



networking bandwagon with NetWare Lite, a low-end, peer-to-peer version of its 
flagship server-based NetWare NOS. In late 1992, Microsoft became the newest 
player to enter this market with its built-in peer networking capabilities in Windows 
for Workgroups. 

Critics are quick to point out that Microsoft is not providing another peer 
network operating system but merely adding simple file and print capabilities to 
Windows. Additionally, it does not support any "clients" except Window's clients. 
In contrast, all major peer NOSs support DOS, Windows, OS/2, and Apple's 
Macintosh. However, for current Windows users, upgrading to Workgroups may 
be a good step. 6 

DC NETWORK-TO-NETWORK CONNECTIONS 

Transmission Control Protocol/Internet Protocol (TCP/IP)--In the 1970s, 
Transmission Control Protocol/Internet Protocol (TCP/IP) was developed by 
ARPA to connect incompatible computers used by military suppliers and 
researchers. It is a set of protocols that are compatible with the ISO/OSI reference 
model. 

Today, TCP/IP is emerging as the protocol of choice for interconnecting 
LANs. And, it has achieved the promise of open systems as today's de facto 
standard for open networking. 7 Often referred to as the TCP/IP suite of protocols, 
the suite comprise a set of protocols that define a variety of network applications, 
for example, file transfer and virtual terminals. 

While NetWare has a dominant position in the LAN-server marketplace, 
TCP/IP is the de facto standard for internetworking between diverse computing 
systems. One needs to consider interoperability implications between the choices 
of TCP/IP protocol and NetWare's IPX/SPX communications environment to 
appreciate the magnitude of this problem. 

Repeaters— A repeater is used when a cable needs to be extended beyond its 
recommended maximum length. Because the signal becomes weakened the further 
it travels, a repeater is employed to amplify and retransmit the signal. 

Bridges— A bridge is a device that can link two or more LANs to form one 
extended LAN that can span many miles. Bridges eliminate the distance 
restrictions and maximum-number-of-stations limit of LANs In addition, bridges 
act as packet filters and forward data that is intended only for remote LANs. 
Locally destined data remains local. 

6 Caryn Gillooly, "Microsoft Marches Into Peer Net Market," Network World , November 2, 1992. 
^Marshall T. Rose, "Network Management is Simple: You Just Need the 'Right 1 Framework!" 
Integrated Network Management, II , (New York: Elsevier Science Publishers, 1991), pp. 9-23. 
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Gateways— A module, or set of modules, that transforms the conventions of one 
network into the conventions of another (a gizmo that allows you connect one 
person's LAN with a different type of LAN). A gateway acts as a language 
translator and allows two disparate networks operating under different protocols 
to communicate. 

Routers— A router is used in internets (between networks) where more selective 
decision-making intelligence is required to select the most efficient path for the 
"data's" intended destination. It ensures faster traffic flow and can automatically 
provide for detours if a connection is broken along the path. 

Brouters— Synchronous line bridges, or brouters, forward packets from one LAN 
to another across bandwidths up to 2 Mbps. It is invisible to most protocols, so 
the entire extended LAN looks like one LAN. 

Hubs— To wrap up this section, a few words about hubs. Hubs range from simple, 
passive devices at the low-end to multifunction devices that include integrated 
bridging and routing at the high-end. To qualify as a hub, it must be capable of 
receiving a data signal and repeating it simultaneously to multiple wires through 
connections call "ports." 

Future Directions— The latest happenings in the "internetworking" area is what is 
going on with hubs. Price cutting is creating a buyer's market at the low end, 
while vendors focus on advanced features at the high end. Hewlett-Packard, 
3Com, and Ungermann-Bass have cut prices such that cost per port is in the $100 
to $200 range, with many offerings favoring the lower price. With 70 percent of 
the Fortune 500 companies using both Ethernet and token-ring networks, the 
vendors have responded with lOBaseT, low-cost hubs. Many vendors are 
incorporating bridging and routing modules into their hubs rather than require 
customers to by separate units. In terms of media, all major media choices are 
covered in today's product offerings. And, Simple Network Management Protocol 
(SNMP) has pretty much become the de facto standard for hub management. To 
describe its operation, in simple terms, SNMP agents capture device and network 
information and forward that data to conveniently located SNMP management 
stations for processing and display. Although it is greatly criticized as a light- 
weight protocol, it is easily implemented and requires the minimum resources to 
operate. 8 

One of the hottest topics in today's LAN hub discussions is asynchronous 
transfer mode (ATM). Utilizing 53-byte fixed-cell relay transport technology, 
ATM is a transfer mode for switching and transmission that efficiently and flexibly 
organizes information into cells. It can be used in both LANs and WANs to 
provide high-speed (150 Mbps+) seamless integration of wide-area, campus, and 

8 Salvatore Salamone, "The Hubbub About Hubs," Network World . June 1, 1992, pp. 47-50. 

330 

362 — 



9 

ERJC 



desktop-LAN transport. But, for now ATM is a "future" technology. Over the 
next several years, expect Ethernet, token-ring, and FDDI to continue to dominate 
communications to the network users. 

X. CLOSING THOUGHTS 

The economic proof of the value of adopting and sticking to a certain LAN 
architecture is desirable but often difficult to illustrate. Typically, each campus 
unit seeks to install a network at the lowest possible cost. However, the sum of 
these unit costs often add up to a sum greater than the whole. If we end up with 
separate and not interoperable or adaptable LANs, the campus can lose out. 
"LANarchy" costs big bucks through lost opportunities. 

In closing, let us consider, "What makes networking successful?" There is 
downsizing, restructuring, and destructing going on everywhere. One thing is 
constant— people make systems work! 

First, no matter where "networking" is located in your organization, one 
needs to give the networking techie the executive clout to carry out this important 
function. Secondly, the more direct the line from that networking guru to the 
organization's top technologist or manager, the greater the possibility of successful 
networking. 

Nationally, there are over one hundred network users for every technical 
support person. And, when we think of their typical day, most of our "techie's" 
time is spent putting out our"fires" and the rest of their time is spent in the 
catching their breaths. Operating in such a crisis mode, we need to help the 
networking staff by making time for them to grow and develop their skills and 
abilities. Unless we help them grow in breadth and depth, job hopping will occur. 
Who knows, one day we might just develop structure and positions so networkers 
will have normal patterns of promotion and career-pathing. We are all too familiar 
with the saying that can be adapted to our networking staff. "Techies do not 
necessarily managers make." I close with this plea! As we work to develop good 
networks, let us adopt the slogan--"support your local techie!" Help them develop 
as professionals. People DO make a difference! 




CUMREC 

■AVUM ' . JA* 

UNivmrnr 

Boll 




(San Antonio 





INFORMATION 
TECHNOLOGY: 

The Revolution 
Continues 



EMERGING TECHNOLOGIES 

M4-5 

Evolution of Smart Card Technology: 
Impact on Higher Education 
Information Systems 



Bill R. Norwood 

Florida Stat© University 



38th Annual 

College and University 

Computer Users Conference 

Hosted by Baylor University 

in San Antonio 

May 9- 12, 1993 



- 365 - 

332 



Evolution of Smart Card Technology: 
Impact on Higher Education Information Systems 



Bill R. Norwood 
Associate Director 
Administrative Information Systems 
Florida State University 
104 William Johnston Bldg 
Tallahassee, Fla 32306 
904-644-0065 



Introduction 

At Florida State University we have been evaluating 
alternatives to our student identification card since 1985. 
Numerous companies and technologies have been reviewed in an 
effort to add functionality to the student identification 
card called Seminole ACCESS. 

One of the keys behind the success of the project was 
focusing attention on how the university ID card could 
become a card smart enough to provide the focal point for 
improved and new campus-wide services. Services were 
interpreted to reference all facets including administrative 
and academic, financial and informational, as well as 
security. 

This paper is the result of our effort to identify 
technology and concepts that could be used today to increase 
the number and types of services provided to card holders. 
At the same time, the technologies were being evaluated to 
determine if they would support a future migration to chip 
card technology. 

We were also looking for cost effective solutions 
requiring a minimum of systems application and other support 
staff, not limited by growth, to provide a wide variety of 
uses. How this has been accomplished to date revolves 
around magnetic stripe technology interfacing with 
mainframe, personal computers and hand held systems. 

Background 

ACCESS cards in use today rely on interaction with 
various software applications and hardware components, which 
gives users the impression that ACCESS cards contain a lot 
of information themselves. Therefore, we like to consider 
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the ACCESS card a Smart Card, although most people consider 
a Smart Card to mean a chip card. The types of magnetic 
stripe applications implemented to date have been limited 
due to inadequate storage capacity, as well as certain 
processing restrictions. 

A campus-wide committee for ACCESS was formed and 
almost immediately started asking for solutions to problems 
that centered around informational needs. Many of these 
needs focused on the way the university used the previous 
photo ID card. Some of the needs were to; 1) indicate 
whether or not the student was currently enrolled, 2) 
ascertain eligibility to buy athletic tickets, 3) use the 
recreational facilities, 4) check out a library book, 5) and 
enter computer labs. 

The need for timely information regarding a card 
holder's status was apparent and if the ACCESS card was to 
answer these needs, a new methodology was going to have to 
be developed along with the appropriate technology. 

Previous contacts with companies like CBORD, Griffin, 
Harco, Danyl and Debitek led us to believe we could use 
magnetic stripe technology. These were proven applications 
installed in campuses all over the country using proven 
technology, yet there were still concerns on certain aspects 
of these systems. 

These concerns included: 

1) substantial additional hardware and communication 
requirements because of the dependence on 
information from other systems. 

2) an inability to use existing terminals to access 
student status or process transactions when 
maintained in other applications. 

3) the requirement for substantial local staff 
involvement from both the systems and programming 
support and financial processing units. 

4) non-standard coding of information on the magnetic 
stripe and security of information. 
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Many of the systems reviewed were considered too costly 
to implement, or did not offer the range of applications 
defined. All of the systems, including ACCESS, use the 
card to activate a specific application or to simply act as 
an identifier, not a carrier of information like a chip 
card. Present and future magnetic stripe card uses will 
have to continue to depend primarily on other information 
processing systems to give them life. 

The chip card technology reviewed during this period 
was both encouraging and discouraging. Encouraging because 
of the tremendous potential indicated by the chips ability 
to maintain true security of the stored information and 
processing capabilities. Discouraging because of the high 
cost of the chip card and the lack of applications. The 
best technology is worth little without the benefit of 
practical applications. 

Thus, what was available in the marketplace left us 
with a simple decision; go with the broad range of 
applications readily available for magnetic stripe 
technology, or choose the more expensive chip card 
technology that offered few applications and limited 
hardware. The decision was made to use magnetic stripe 
technology with a standard bank encoding scheme, which 
allowed a choice of vendors rather than a single system. 

Old Problems/New Approach 

If the best available and most affordable technology is 
magnetic stripe, how do you make magnetic stripe technology 
appear to be smart? Our answer was to first take our host 
based applications and allow the ACCESS card to interact 
with those applications in several different ways. 

Some of those ways were: 

1) student self inquiry terminals facilitating access 
to student fees, schedules, etc., could be 
installed if the ACCESS card could be used to 
invoke the existing CICS screens developed on the 
mainframe. 

2) cashiers' office staff could use the ACCESS card 
to bring up the students' record when paying fees 
saving time, key strokes while improving services. 




3) download host-based information to hand held 
devices which can then scan the ACCESS card to 
gather usage information or certify eligibility. 

4) same hand held devices can be used to assist in 
taking attendance in large lecture halls. 

5) download host-based data base with housing 
indicators to personal computer based campus 
security system. Students then use the ACCESS 
card to enter dorms, etc. 

Everyone using the ACCESS card, students, faculty, 
staff, get the impression the card is doing all the work 
when in reality, other systems being activated or called by 
the card are making the decisions. Administrative offices 
are beginning to see ways to use the card to assist in the 
day to day operations of their areas. 

One example of new ideas is to use the ACCESS card to 
print equipment check out sheets in student recreation 
areas. Simply have the card presented, swipe the card 
through a magnetic stripe wedge reader attached to a 
personal computer keyboard, extract the identification 
number of the card and the name of the card holder, then 
print the check out sheet with a date and time stamp. 

Another example is to use the ACCESS card for 
controlling access to information on employers looking for 
student workers. Our financial Aid office operates a job 
locator service for students. Any available jobs are posted 
on a large public bulletin board located at the student 
union. Over half of the jobs posted for students go to non- 
students. 

Surplus Telex terminals equipped with magnetic stripe 
readers and connected to the university mainframe are being 
installed in the student union lounge. Students with ACCESS 
cards will be able to look up jobs by using the ACCESS card 
and their personal pin number to gain entry to the 
information. Others without ACCESS cards or not currently 
enrolled will not have access to the information. 

Our second answer was to allow the ACCESS card to have 
true financial processing capabilities like a bank card. We 
quickly discovered there were no chip card applications in 
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the financial world in either ATM or point of sale devices, 
nor were any planned in the near future. Therefore, our 
only choice was to use the encoding standards and magnetic 
stripe technology used in the banking world for bank cards. 

Many of the old problems facing automation in the 
university environment revolve around financial transaction 
processing. Payment of fees, tuition, financial aid and 
cash collection campus wide all present challenging issues 
and opportunities. 

Tremendous financial processing capabilities exist 
today in banks and financial service centers. By tying the 
ACCESS card to the financial world with a service agreement, 
we use the card both as a financial transaction card (debit 
card) and as a university ID card. The bank system handles 
on-line authorizations and supports the declining balance 
concept inherent in a debit card operation. 

Access to the bank card center is achieved through 
inexpensive credit card readers already in use on campus and 
our existing administrative network (3270 SNA) connected 
directly to the bank center host for processing certain 
kinds of transactions. Other financial processing features 
include; posting and depositing payments, access to ATM's 
state-wide, electronic transfer of funds, and a card used at 
over three hundred merchant locations in Tallahassee. 

Information Systems and ACCESS Today 

Applications and the associated information systems are 
a key part of every higher education institution. With 
budget constraints and increasing demand for services, many 
of the problems needing resolution are simply put on hold. 
The ACCESS card concept brings a different perspective to 
information systems. 

Our perspective was: 

1) use existing applications when possible. 

2) interface with other systems when needed. 

3) utilize mainframe, personal computer, hand held 
or other speciality hardware. 

4) focus on services provided through a single card. 
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5) use the card to generate either cost saving or 
revenue generating opportunities. 

This approach allows information systems to utilize 
mostly current applications and not have to develop new 
ones. Existing CICS screens can be used to display 
information or collect money using the ACCESS card with 
minimal change. Commercial offerings are available to suit 
many specialized applications , such as security control and 
ID card systems. These offer the advantage of being ready 
to install after little or no modif ication, as opposed to 
dedicating staff for design , development and maintenance of 
such systems. 

Information Systems and ACCESS Tomorrow 

The way information systems and the ACCESS card work 
together today and what we expect tomorrow are still 
developing. As noted earlier, we are planning for the 
migration to chip card technology in the future. Chip card 
technology and ACCESS technology will soon co-exist on the 
same card. Recent developments are showing the card of the 
future (two years) using both magnetic stripe and chip card 
technology. Manufacturers are now making chip card readers 
for parking gates, newspaper racks, subways, toll roads, 
coke machines, stamp machines and more. 

Why do we want to migrate to the chip and what are the 
benefits to information systems? First, we need to 
understand some of the benefits of using a chip card versus 
the magnetic stripe. Chip card readers have no motorized 
parts, much like swipe readers for credit cards. Without 
motorized movement, readers will cost approximately thirty 
to forty percent less and have virtually no service 
requirements . 

The actual chips used in the cards could be Datacard 
chips, GEM Plus chips or others. What is important is each 
chip is a computer within itself, some complete with their 
own operating system residing on the chip and security 
systems that challenge any device trying to read the 
information contained within. Some even use sophisticated 
algorithms to scramble the data encoded on the chip, 
separate the chip into compartments like directories, and 
allow multiple users and applications to co-exist on the 
same chip. 



Chip cards can have storage capacities ranging from 
several hundred bytes to thousands of bytes allowing data to 
be stores, updated, etc, each time the card is used. Memory 
capacity of the chip and the quantity ordered determines 
cost. Low end memory chip cards ordered in large quantities 
today cost around ten dollars each. 

Information systems of the future can use the chip to 
transport information, track usage of facilities, control 
security system access, frequency of check cashing, test and 
class attendance and counseling notes just to mention a few. 
We have heard talk for several years about students carrying 
their transcript around on a card, perhaps that is closer to 
reality than we thought. 

How far chip card technology has come and the variety 
of applications being developed today are fascinating. 
Imagine walking into the university testing center to take a 
test and the proctor asks for your ACCESS card, and inserts 
it into a small hand held reader. Upon insertion, the 
digitized imaged of the card holder is pulled from the chip 
in the ACCESS card and displayed on the small ^screen for 
verification by the proctor. 

Self-inquiry stations using chip card technology may 
even become information update stations. As an example, 
every time a student uses a self -inquiry station, pertinent 
data could be loaded to or from host based systems, or 
information in the chip could simply be updated. The latest 
address on the student could be loaded to the chip and the 
next time it is used in a department, transferred to the 
departmental information system. 

Paying for Tomorrows Technology 

Funding new projects or technologies in higher 
education today is one of the challenges we all face. 
Convincing the university to invest in ACCESS card 
technology, install card readers, purchase security system, 
etc, will be nearly impossible unless new revenue sources 
are identified. We have identified several opportunities 
presenting new revenue sources. 

Some of those identified are as follows: 

Debit Card - Now that 34,000 ACCESS cards are in 
circulation, every student, faculty and staff member 
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can use the debit service offered through a 
financial institution. Every time the card is used 
for debit transactions at any of the three hundred 
merchants, revenue is generated for the ACCESS 
program . 

ATM Access - Access to the many services of the 
banking world , such as Automated Teller Machines 
(ATM) , has many advantages. The ATM network in 
place throughout the country can be used by students 
to access their university debit card account, 
saving the university considerable expense in the 
distribution of student refunds and financial aid. 
At the same time the university is saving money in 
administrative processes, every cash withdrawal by a 
card holder creates revenue for the ACCESS program. 

Photo ID/Access - The new digitized photo card used 
for the ACCESS card costs sixty percent less than 
the Polaroid type picture used for the previous ID 
card. Flexibility of the new Datacard equipment is 
such that chip cards can be created in the future 
with the same equipment. 

Long Distance Calling Card - One of the newest 
innovations for generating revenue comes from the 
ability of the Datacard equipment to print on the 
front and back of the ACCESS card. By adding a 
calling card number to the ACCESS card, the 
university expects to generate a considerable 
amount of ongoing revenue. 

Campus Copier Program - With the added pre-paid 
value stripe on the ACCESS card, students may also 
use the card to make small value purchases from 
copiers, coke machines, etc, all over campus. 
Every time the card is used in one of the 
operations, revenue is generated for the ACCESS* 
program. 

Market Research - Useful demographic information is 
being collected about who buys various products out 
of vending machines, who uses the recreational 
facilities, etc.. Correctly packaged, this 
information has value to marketing firms doing 
consumer purchasing studies. 
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Summary 

Migration to a chip card and the ensuing benefits to 
the university will take time and funding. Financial 
institutions are now beginning the integration of the chip 
card with a bank card. Soon, in some areas of the country, 
you will be issued a new ATM card with both a magnetic 
stripe and a chip. The intended use of the chip is for 
small value transaction processing in applications like 
vending, toll roads and subways. This will lead to 
applications and equipment development supporting chip card 
technology, paving the road for a gradual migration to chip 
technology. 

Information systems will continue to find ways to 
utilize the technologies presented through the ACCESS card. 
New approaches for providing better services and reducing 
costs of existing operations for the university today will 
be discovered while planning for the next generation ACCESS 
card and the future applications. 

At the same time, every possible way to create revenue 
streams will be explored, including forming business 
partnerships and consortiums to develop new applications for 
magnetic stripe technology and the exploration of chip card 
technologies. Tomorrow's new applications in higher 
education are waiting for us to find ways to make them 
either cost effective or revenue generating. 

Experience to date with this program has enabled us to 
provide cost-effective solutions for old problems, and at 
the same time, implement a comprehensive card system 
offering tremendous opportunities in both future problem 
solving and revenue growth. 
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About Iowa State University 

Iowa State University, located in Ames, Iowa, is a broad-based university of 
international stature, with an enrollment of more than 25,000, including students from 
all 50 states and more than 100 other nations. 

As Iowa's land-grant institution, Iowa State University (ISU) provides high 
quality education for undergraduate and graduate students in the land-grant tradition 
of combining practical programs with the liberal arts and sciences. Its research in 
agriculture, science, technology, and other areas addresses some of the most impor- 
tant issues facing Iowa, the nation, and the world. Its outreach and extension efforts 
are creating the technology transfer and distance learning programs that will serve 
Iowa into the twenty-first century. 



In conjunction with ISU's long-standing history of scientific inquiry 
and technological growth, the ISU Administrative Data Processing (ADP) 
Center operates in an atmosphere that fosters the investigation and application 
of new technology. The project that provides the background for this paper is part 
of that tradi f ion. 



General Theory 

Visionary thinking about long-term strategies for handling corporate information generally 
focuses on a complete, electronic system to capture, store, manage, and process information. 




Such a complete strategy seems relatively straight forward for many to visualize. Also, 
many influential organization members believe such an electronic world will probably comprise the 
most effective and efficient way to do business in the future. However, those of us who are in the 
information technology delivery 7 business must deal with the tactical and practical aspects of 
directing an institutional environment toward such a vision. This paper presents the background, 
accomplishments, and future implications of moving toward an electronic administrative informa- 
tion environment at Iowa State University. 

Background 

Reducing paperwork has been a major objective at ISU for the past 20 years. As else- 
where, some answers for paperwork reduction, or containment, have come through microfilm, 
microfiche, on-line systems, and the electronic movement of data among using entities. Now we arc 
at a point of needing to move electronic information systems deeper into the business processes of 
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our university to further enhance operations and to make another impact in paperwork reduction. 
ISU's administrative vision is to have most university documents available electronically in 
appropriate locations and to appropriate personnel. 



Vision for Document Accessibility 

Capture - j Store 




A major technical concept currently available for supporting such a move is referred to as 
IMAGE PROCESSING. Conceptually, image processing can be thought of as including all forms 
of electronic documents, such as documents created on paper and later scanned into electronic 
form, documents originated in electronic form but never put on paper, electronic pictures, and 
various other items. 

At Iowa State University, image processing generally means a system that captures 
documents electronically and manage? the business processing of those documents under computer- 
ized control. On-line applications that handle data in document form rather than some structured 
data form are good examples of such image processing; however, not many such complete image 
document processing systems exist today. This is an area that is expected to get increased attention 
in the future. 

Another approach is that of scanning paper documents (including signatures, emblems, 
etc.) into the computer system and having the system handle the storage, distribution, and process- 
ing of the documents under system control. In the future, other electronic image forms can then be 
integrated into this approach. Such is the system the ISU ADP Center has installed as a first 
implementation in the University's Financial Aid Office. 

This image processing system enables the ISU Financial Aid Office to electronically 
capture, store, retrieve, display, process, distribute, and print visual information not already in 
digital form. This image processing system works in a distributive processing environment in 
which the central processing unit acts as a server and work flow manager but does not read or 
interpret the content of a document. 
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Graphic Overview of Image Processing 
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Scanned Document Image Processing at ISU 

During the past three years, ISU has gone through the educational, promotional, prioritiz- 
ing, planning, funding, piloting, and production implementation of an electronic document process- 
ing system for the financial aid function of the University. 



The educational and promotional efforts at the University were mainly driven by the ADP 
Center staff. The director, associate director of university systems, and key analysts actively 
communicated with University administrators about the possibilities of image processing and the 
benefits it could bring in the form of quality, performance, and long-term cost containment. The 
process included a literature review and productive discussions of the pros and cons of image 
processing. In general, this led to an atmosphere in which working together toward a common goal 
of reducing paperwork and improving quality became the consensus of those involved and particu- 
larly those who were to make the overall decisions to change business processes. 

After a consensus was reached, several offices (Purchasing, Admissions, Financial Aid, 
Registrar, Accounting) were studied to determine where a pilot project using image processing 
would be most appropriate and have the greatest impact. This study revealed that the University's 
Financial Aid Office (FAO) was well suited to a project of this type, and in March of 1991, a pilot 
project on image processing was begun in that office. 



IMAGE Processing Pilot Project 

As a participant in the project, the Financial Aid Office was interested in discovering if 
image processing was technically appropriate in its environment and in seeing if image processing 
could help the Financial Aid Office staff accomplish the following long-term goals: 

•Enhance student recruitment and retention. 
•Reduce document turnaround time. 
•Make better use of staff time. 
•Improve accountability and manageability. 
•Reduce errors. 




-381 - 



Paper-Based Operations in the Financial Aid Office 

The study revealed that the Financial Aid Office was a prime example of the kind of office 
that can benefit most from implementing an image processing system, It is an office with a high 
volume of documents and an office that interacts with student information databases used by the 
Registrar's and Admissions Offices. The office handles forms from approximately 20,000 appli- 
cants per year. These forms arrive at a rate of 1,500 per day during peak application times (see the 
graph below). In total, the Financial Aid Office at Iowa State University receives and handles 
approximately 175,000 to 200,000 forms per year. In the paper-oriented system, 25,000 to 30,000 
student folders are maintained, in which all documents received are filed. Each year the staff purges 
all inactive file folders to a second storage site where they are required to be kept for another five years. 



Monthly Cycle of Document Arrival 



35000 

30000 

€ 25000 
g 

£ 20000 

n 

§ 15000 
* 10000 
5000 



Montht 



The old procedure (shown by the graphic at the top of page 5) for handling the inflow of daily mail 
is as follows: 

1 . Open daily mail received. 

2. Sort and stack mail by type of document. 

3. Look at each document, highlight special areas for quick visual reference, encode special 

processing considerations or identifying labels onto the document, and staple multiple 
forms together where necessary. 

4. Place documents in in-baskets of appropriate office staff or functional area. 

5 . Have each unit pickup documents, process them (including logging the receipt of the 

document on the host document tracking system), and either pass them on to another office 
staff member/functional area or send them to the mail room for fileback. 

6. Have staff work on fileback of documents as staff availability and time permit. 

The volume of documents received by the Financial Aid Office makes even this simple 
process cumbersome, time-consuming, and error prone. The impact of this paper processing 
procedure on student services is most apparent in the following areas: 

1 . Only one person is able to access a document at any given time. 

2. Documents can be misplaced or misfiled. 

3. The confidentiality of the information on these documents can be compromised. 

4. There is no audit trail showing where the document has flowed and what has been done. 

5. Determining the amount of work in progress, backlog, and time flow of documents is 

difficult. 
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Overview of Paper Flow 
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Details of the Pilot Project 

The pilot project entailed three tasks: defining the process, testing the process, and imple- 
menting the process on a controlled scale. 

Defining the Process: Defining the process required an analysis of the size of each document to 
be scanned, identifying the quantity and flow of documents coming into the Financial Aid Office, 
and determining the length of time documents would need to be retained on each storage medium. 
The information gathered from this type of analysis became the basis for defining the type and 
amount of storage needed to implement the project and helped determine a policy for controlling 
document migration between the various storage media. 

Possibly the most significant information gathered during this analysis was establishing 
how large digitized, scanned images are and recognizing how much space is required to keep 
scanned images available on fast-access storage devices. The table below shows the sizes of some 
typical FAO documents and the amount of storage needed to keep a year's worth of these documents. 



Table of document sizes and storage needs 





Scan 


Annual 


Storage 


Document 


Size* 


Number 


Requirements 


Award Letter 


56,000 


17,500 


980,000,000 


Tax Return (State/Federal) 


57,000 


10,000 


570,000,000 


Electronic Student Aid Report 


56,000 


15,000 


840,000,000 


Transcript 


43,000 


2,000 


86,000,000 


GSL Check Letter 


16,000 


20,000 


320,000,000 


Institutional Verification Form 


40,000 


6,000 


240,000,000 


Entrance Interview Loan Form 


16,000 


2,500 


40,000,000 



This size represents, in bytes, the 'compressed' IMAGE storage requirements per document. 
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Another important aspect of the definition phase was the development of an electronic 
student folder, which became the structural core of the document-handling process. The folder was 
developed with an eye on the long-term goal of having most student information available in an 
electronic folder any place on campus. The folder structure was based on student ID, office or 
functional area first responsible for the document, and the operating year of that office or area. 




Other tasks in this early phase of the project included specifying equipment (see the list 
below), establishing security procedures, determining document routing, and identifying document 
characteristics. ADP Center systems and technical support staff participated in this phase of 
development by installing host software and establishing network/communications protocols. 



Equipment List (Numbers in parentheses indicate number of items to be used in full implementation) 
OS/2 Workstations 

6 (3 1) - PS2/57 SX (20 MHz), 8MB RAM, 80 MB Hard Drive 
8508 workstation display (19", 1,600 x 1,200 resolution) 
Token Ring Card 
Image Adapter Card 

1 (3) -4019 IBM Laser Printer 
1 (2) - 2456 IBM Scanner 

Physical layout - four office areas physically located on different floors 
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One collateral development that occurred during the definition phase was the Financial Aid 
Office's decision to revamp its office procedures. Recognizing that the pilot project presented a 
good opportunity to phase out old methods and implement new ones, staff in the FAO examined 
document handling procedures, including methods of identifying, routing, and classifying documents. 

Testing the Pilot: Once the limits and needs of the project had been defined, the testing phase 
began. Testing included scanning all types of documents the FAO processes. During testing, 
special attention was paid to such details as document size and orientation, shading, paper color, 
and the readability of the fine print on forms. 

During this phase, the typical image workstation was tested along with the host and 
network software. The hardware and software for the pilot project were installed during late 1 99 1 
and early 1992. By mid-1992, the testing phase of the project was complete, and the document- 
processing phase of the pilot began. 

Implementing the Pilot Project: The implementation phase included training for one support 
person to run the indexing and scanning operation and training for one experienced financial aid 
counselor to work with the scanned documents. All documents for that counselor were scanned and 
then processed electronically. 

The advantages of this method of implementation were the following. It limited the number 
of documents handled while providing a complete sample of all documents handled in the FAO. It 
provided a known group of documents available on the IMAGE system for all staff to view, and it 
allowed experienced staff members to comment on and critique the flow process. 
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Results of the Pilot Project 

Since June of 1992, the FAO has been handling ten percent of its documents through the 
image scanning process. Based on the results of this controlled implementation, the pilot project 
has been judged successful on all counts. Image processing is being recognized as a useful way of 
moving from a paper-dominated environment into an environment in which documents are handled 
electronically and paper use is minimized, 

The pilot project has shown that this leading-edge technology can eliminate paperwork and 
improve services in the Financial Aid Office at Iowa State University, With the technology, 
documents received are immediately scanned into the IMAGE processing system, automatically 
filed, and electronically routed to the appropriate office staff or area to answer student and office 
needs. FAO staff then work the documents electronically via electronic menus (see the appendix on 
page 1 1), with no paper flow in the office. With the IMAGE system, student paper folders are 
replaced by electronic storage. 

Implementing the pilot project with the IMAGE processing system has led the Financial 
Aid Office to anticipate that the following benefits will accrue with a full production version of the 
system: 

1 . Quality of service to students will be improved, with quicker access to documents and 

document history, automatic filing and logging of documents, document security, and the 
availability of disaster recovery for all document images. 

2. Office productivity will be increased by eliminating document delivery, filing, and refiling. 

All Financial Aid staff will have access to all documents concurrently so no time will be 
lost retrieving or searching for documents. 

3. Office space will be used more efficiently by eliminating the need for file storage cabinets 

because no paper filing is necessary with IMAGE. Purchases of supplies necessary to 
support paper filing will decrease and eventually stop, 

4. Documents from related campus offices will be filed in one electronic folder to give FAO 

staff access to all iaformation pertaining to a student. 

Overall, the Financial Aid Office believes that image processing will allow the office to 
meet its goals. The FAO expects to achieve an annual savings of approximately $16,000, and 
anticipates being able to reassign and reclassify staff to provide better service to students. The 
diagram at the top of page 9 shows a comparison of the paper and electronic flows in the Financial 
Aid Office at Iowa State University. 
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The main technological thrust of this innovation is that it shows the Financial Aid Office at 
Iowa State University can be converted from a high-volume paper office to an electronic forms 
operating environment, a step on the journey toward an electronic administrative information 
environment at ISU. The diagram below offers a graphic comparison of the paper environment and 
the electronic environment that results from image processing. 
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Future Implications 

The benefits of image processing have become more apparent in the last few years. 
Businesses with extremely high paper volumes, such as insurance companies, were the first to use 
it seriously. Our work shows that image processing systems can also prove to be very beneficial in 
a university environment. Some future benefits we. foresee in conjunction with image processing are 
automatic data capture via Optical Character Reqflfckion and bar-coding of source documents for 
faster processing. Any computer printed document onteport could be automatically added to the 
student's folder without it ever being printed. 

Image processing applies to all aspects of the university environment. The process can be 
applied not to only student folders, but also to policy and procedure guides, business office pro- 
cesses, purchasing forms, etc. The IMAGE processing system interacts with existing databases at 
ISU in order to verify and enhance existing student information. It is also possible to share docu- 
ments electronically with other compatible IMAGE processing systems at other institutions. 

The system is unique because it is fully integrated with other university databases and was 
developed by Iowa State University ADP Center staff through a partnership project with IBM 
ACIS and the IBM Des Moines Branch Office using IBM's ImagePlus software. Personnel from 
ISU's ADP Center, Financial Aid Office, and IBM were heavily involved in the implementation. 

The IMAGE processing system is currently being used to handle ten percent of the docu- 
ments received by the Financial Aid Office. The system is scheduled to be fully implemented in the 
Financial Aid Office in 1993. 



Appendix: IBM ImagePlus System Screens 



Screen 1: Sample Electronic Menu 



Folder Application Facility 



Select one of the following functions and press Enter. 

1 . Get work 

2. Windup 

3. Folder functions 

4. Document functions 

5. List folders 

6. List folder contents 

7. Workflow functions 

8. Supervisory functions 

9. Sign off 



Command 



> ADOR 123456789FAl992,Awdltr 



F1 - Help F3 = Exit F1 2 = Cancel 



This screen illustrates the main functions of the 
ImagePlus system. At the user's workstation, the 
get work option displays the next image in the 
in-basket that is ready to be worked. The windup 
option completes the work on a particular image. 
Options 3-6 allow the operator to view folders and 
documents on file and perform various functions, 
such as update, delete, move, and route. The 
workflow option allows personnel with appropri- 
ate access to view the workflow of any folder or 
routing queue. Through the supervisory option, a 
user's profile information or workflow assignments 
can be viewed or updated. The user also has the 
option to enter shortcut commands, such as ADOR 
(add document and route), to perform a function 
without using the menu structure. The command 
shown in screen 1 would skip screen 2 and display 
screen 3 directly. 



Screen 2: Sample Document Function Menu 



Document Functions 

Type information, then tab to the menu selection field and 
select an option. Press Enter. 

Folder ID . . . 123456789FA1992 
Form number . . awdltr 
User exit data 

1 1 , Add and route document 

2. Add document 

3. List folder contents 



Command = = > 



F1 -Help F3 -Exit F1 2 -Cancel 



This screen would appear if a user 
selected options 3 or 4 from the menu 
shown in Screen 1 above or left the 
document name (awdltr) off the 
command line entry. The folder ID is 
carried forward from the initial screen 
if it was entered on tlie command line. 
The user would need to enter the 
document name (awdltr), any user exit 
data, and the option. Choosing option 
1 , which is the normal choice when 
processing a document, would result 
in screen 3 being displayed. 
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Screen 3: Sample Add and Route Document Screen 



Add and Route Document 123456789FA1992 

123456789 SMITH JOHN DEAN PES MOINES IA 03330 

Type information and then press Enter. 

Form number . . : AWDLTR Security class . . . 01 

File tab PRE-DSBS Date received 12/1 6/1992 

User defined date 

Pape/Kept .... 2 1. Yes 2. No 

Description . . . Award Notice 

Comments . . . 

Do you wish to route? 2 1 . Yes 2. No 

Routing line of business . . . SF 
Transaction type AWDLTR 

Temporary ID for scanning . . : 534472 

F1 =HelpF3=Exit F6=Routing details F12=Cancel 



This screen is completely filled out from information that the user has entered previously or that is stored 
on the Image system. The operator can override almost any field if necessary. If all data is correct, the 
operator simply presses [Enter], The system will then respond with a 'Temporary ID for scanning* number. 
This is the number that will be used during the scanning operation to match the scanned image with the 
folder key entered earlier (ssno, office, year). 
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Introduction 

"Today, advanced nations are beginning to build broadband 
communication systems zoith enormous capacity to carry sound, TV 

images, and computer data over glass l\zrs to every home and 
business. These systems will use digital 'on* and 9 off signals rather 
than the waveforms analogous to sound that has been the basis of 
telephone since Alexander Graham Bell. ..Familiar as the warning may 
sound, key industries will likely falter in nations that fall behind in 
building an information highway" (Schefer, 1991 p. 5). 

The key words are "broadband" and "information highway." 
Literally, both "information" and "highway" are everyday terms. But 
developmentally, and together they mean far more than their sum. 
What to look for here is how the ability to store large amounts of data, 
and transmit them is integrated with the computational power of 
electronic computers. Consider the base of machines which are 
required to handle and satisfy the human visual and auditory senses, 
what sort of bandwidths would they have? Such machines must be 
able to sample, digitize, and reconstitute a high fidelity experience. 
These bandwidths are no longer the things of the future because they 
are approximated by the bandwidths we find in high technologies like 
high-definition television (HDTV) and digital audio compact discs 
(CDs). The current Audio CD standard of 0.2MB/ second suffices for the 
bandwidth required for both auditory and oral communication. The 
requirement of 0.4GB/seconds bandwidth for stereoscopic high 
resolution television is the basis for video data. These types of input 
bandwidths are the widest types of video and audio bandwidths in 
current use today. 
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Coupled with massive storage techniques computing is, thus, 
forging ahead into the dawn of a new era with stunning, and 
previously unthinkable capabilities and potentials. One can hardly 
gainsay the fact that both information and computing technologies are 
at the frontiers of the twenty first century! Among the latest mysteries 
and perplexities associated with computer media, especially image- 
based media, are how to resolve the deep puzzle of reality. Computer 
media have become not only complex and multifaceted, but are also 
intriguing. Current fascinations with it as a medium are associated 
with different types of modern technologies such as Artificial Reality, 
Cyberspace or Virtual Reality which provide information in three 
dimensions; Optical Technologies - including laser as in 
Videodisc/Laserdiscs and CD-ROM, among others; Multi-Media and 
Interactive Video - with an infusion of sound, images, animation, 
video and words or text; Artificial Intelligence - Expert Systems, 
Natural Language Understanding, Speech Recognition, and Neural 
Network systems; and Robotics. We do really live in exciting times - 
not only because of what is available, but also the challenges that face 
us each day in the choices we make as information systems builders 
and deliverers. 

Surely the information revolution has affected the various 
aspects of modern living. Arriving at this information age required 
overcoming many institutional climate and cultural roadblocks, 
technical problems and economic hardship. If we could pause for a 
minute and articulate why the revolution, we shall arrive at the 
conclusion that the revolution was inevitable. But then, what did the 
revolution bring? What is ivs impact? What has changed? Neither 
time nor space permits an exhaustive discussion of these issues. 
Suffice it to say that first, the way we receive information and send 
information has also changed; second, the way we store 
data /information has changed considerably; and third, and perhaps 
most important, the way we conduct business has changed. 

Three major examples (electronic publishing, visualization 
technologies, and multimedia) are used to illustrate these points. (A 
fourth and an emerging technology, virtual reality is briefly discussed 
as a promise near the end of the paper). We begin with electronic 
publishing that has made possible an emerging industry in its own 
right, and that includes electronic production and electronic 
distribution. Electronic data can be made available through different 
types of network facilities such as global electronic libraries, on-line 
access and database search services. So, the information you need is at 



your desk when you need it and how you need it! Another major 
source is through visualization and scientific visualization, in 
particular, bombards us with images and animations ranging from 
simple scientific processes like the emergence of a butterfly from a 
pupa, to planetary exploration, scientific simulations and 
reconstructions which, to say the least, befuddle the mind. Video 
technology tops the list in the visualization arena, and has played a key 
role in this information age. As if these technologies were not 
revolutionary enough in and of themselves, there came the 
penultimate world of media integration, known in popular literature 
as multimedia. (I believe the ultimate is virtual reality!). Simply 
stated multimedia is a mixture of different monomedia. Think about 
this for a minute.. .a technology mix of video, audio, graphics, 
animation, and text. ..and you can appreciate the power inherent in 
these media sources, individually and collectively, in any combination. 
As a matter of fact, one of the challenges of multimedia is how to 
navigate the maze of combinatorial mixes that range from type of text, 
to color mixtures to arrive at media mixes that make the most sense in 
a given context. 

The thrust of this paper dwells on the salient features or factors 
which make multimedia so powerful and so irresistible as a modern 
delivery or communications medium. Illustrations are provided 
where necessary from the major experiences we had in building and 
putting in production four multimedia systems at The Ohio State 
University. A fifth project is underway. While it was no easy task, our 
experience will show how we tapped into the communicative power of 
multimedia, making it interactive (that is leveraging the inherent 
power), by allowing the user of the system to take charge. So, power 
and system control reside with the user! 

The paper begins with this introductory portion. This is followed by a 
subsection which explains what interactive multimedia is. The next 
section deals with the sourres of power to interactive multimedia, 
followed by the mission and the challenge we faced at Ohio State. The 
section on our experience and strategies follows. The paper is 
concluded with the section on the promise, and a wrap up. 



Putting Interactive Multimedia In Perspective - What is it? 

The basic building blocks of interactive multimedia are text, 
graphics, animations, audio, and video. Combining these basic tools 
creates a higher level of abstraction and persuasive power among 



ERLC 



3Gi) 

— 397 — 



delivery systems. "Multimedia at its best engages, cajoles, entertains 
and informs,", (Blum 1992, The world of Macintosh Multimedia p.8). 
So, not only does interactive multimedia integrate different 
communications media as no other technology has done, it also 
empowers the user for controlling the interaction. The major 
advantage of interactive multimedia is "you will decide what you'll 
hear and see and read, and in what combination, either simultaneously 
or in a sequence of your choosing. That has never before been possible, 
even in face-to-face human interaction/ 1 (Ted Leonsis 1992, The world 
of Macintosh Multimedia p. 4). Therefore, interactive multimedia is a 
completely new way to communicate. It is a revolution, not just the 
next step in communication's evolution. It is bound to make an 
incredible impact on people in different facets of life. 

Meanwhile, the industries developing interactive multimedia 
tools are defining the field and establishing the intellectual framework 
in which interactive multimedia can be conceptualized. Indeed, two 
companies that are producing the basic tools for multimedia - IBM and 
Apple - have joined efforts to create systems and solutions and are 
creating a new environment for interactive multimedia to sec the pace 
for similar partnerships in areas as unrelated as telecommunications, 
cable, publishers home entertainment and electronics. 



Power sources 

Multimedia has already found uses in different fields - video 
productions; presentations and promotions; visualization; training and 
education; reference materials; and entertainment. The common 
thread is the inherent power of this medium to communicate, plus the 
associated 1 ma which comes with a diversity of media. But other 
sources of i. s is power are related to human perception, and the tools of 
construction used in developing and delivering multimedia systems. 

Perceptual 

Perception is a direct source of power in multimedia systems. 
The computer, the medium of both expression and communication 
signals is also an integral part of the perceptual stimululi. What is 
communicated in interactive multimedia is presence - close to how 
humans communicate. But, multimedia engages the senses in ways 
which no other combination of technologies (except perhaps for virtual 
reality) does. Vision and Audition are two major perceptual power 
sources for multimedia. A third source of perceptual power, but to a 
lesser extent, is haptics. Each of these is briefly discussed. 
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The role of the haptic system 

The human haptic system consists of subsystems which enable 
touch (tactile), kinesthetic (positional sensations) and motor actions. 
Haptics play a larger role in virtual reality than in multimedia, because 
in virtual reality, the user is able to touch, feel, and manipulate objects 
in the environment. Haptic interfaces in the way we have built our 
own systems are limited to forces exerted on screens by simply 
touching the surface for menu selection. 

The role of the Auditory system 

However, one classifies the audible world, either as a wave 
energy or as a collection of acoustic objects, audition does impact 
immensely on multimedia. First, there is spatial sound - that can be 
integrated either as simulations or real spatial localization cues for 
interaction. In our system an audio command such as "touch the 
screen' 1 can prevent possible errors. There are also nonspeech audio 
capabilities that enhance interactive multimedia systems. "In addition 
to spatial location, various acoustic features such as temporal onsets 
and offsets, timbre, pitch, intensity, and rhythm, can specify the 
identities of the objects and convey meaning about discrete events or 
ongoing actions in the world and their relationships to one another" 
(Gary Bishop et al, 1992). It is possible to systematically manipulate 
audio sources and these features to create an auditory symbology, that 
operates on a continuum using literal everyday sounds, or complete 
abstract mapping of statistical data into sound parameters. Design 
principles in music, psychoacoustics and acoustic determinants of 
perceptual organization can become the sources of the design. 

The role of the vision system. 

First is the visual phenomena - Human visual stimuli are 
pervasive and play a dominant role in interactive multimedia systems. 
This visual role is maintained in at least four different ways. There is 
first the characteristic visual image, provided either through images 
synthesized by computer graphics or those provided by video. Second, 
there is the structure of the visual scene that goes beyond the interface, 
but which deals with that fundamental biological image processing 
entity with the capability of distinguishing a foreground from a 
background, and spontaneously way aggregating parts into distinct and 
separate meaningful regions. So, for example, a viewer will recognize 
a tree as being different from a house, and both as different from the 
ground on which they stand. As will be demonstrated in one of our 
systems, a door stands out from its background. 



Third, there are the visual consequences of interaction with the 
screen, that carries with it some realism about the objects that are 
perceived. A user of our system will, thus, see the doors open and 
close, or see the video simulation role and stop. Cutting, 1986, has 
described such visual worlds for virtual reality. A visual consequence 
might, thus, be described as being the spatial interpretation of visual 
images that is very dependent upon the kinematics (abstract motion 
without force or mass) of the image in motion. The nature of motion 
so described becomes the consequence of the user himself or herself. 
Indeed, while some visual consequences are necessary for perceptual 
fidelity, visual consequences are beyond simple visual issues because 
they include intersensory integration. 

Fourth and finally, there is the role of visual information in 
discriminating among different spatial orientations. While a two 
dimensional depiction of some image in two dimensions helps to 
illustrate or simulate real world objects a world view in three 
dimensional graphics can also be used for enhancing and orienting 
such images with more realism. Switching from one to the other does 
not disrupt the orientation of the user (as would sometimes occur in a 
virtual world) because it occurs with dynamism. 

Role of storage medium 

University Systems has used interactive videodisc for the 
development of University Front Door Systems because of its high 
capacity data storage ability and high fidelity of the data. The laser disc 
can hold 54,000 frames on each side, enough to record 40,000 pages of 
text, 5,000 photographs, twelve minutes of moving footage, eight hours 
worth of narrated film strip presented at two frames a minute, and 
1,000 microcomputer programs - only on one digitally encoded disc. 
Video can handle any type of information that can be recorded: print, 
manuscripts, photographs, slides, film, X-rays, tape recordings, all types 
of graphics - including computer graphics. Indeed some discs record 
both analog and digital data, making the potential for 
telecommunications incalculable. This choice has increased 
performance and reduced bandwidth requirement for managing 
multimedia data flow. The disk drive receives commands directly 
from the host computer, and transfers data directly to the TV screen. 
As will be shown in the demo, using any of our systems is almost like 
watching TV video - except that power now resides in the user's hands. 
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I/O speed Increase 

We also garnered power from speed and system response. 
Access time for a video disc can be really brief when compared to video 
tapes. Because in a laser disc player there is no physical contact between 
the moving disc and the fixed head which reads it; the disc smoothly 
glides back and forth beneath the reading head. So, the worst access 
time is really a matter of seconds. On the other hand, in a videotape 
player, both the tape and reading head touch each other, and both are 
involved in motion, so access time can take longer because the two 
(tape and reading head) must disengage and the tape must wind from 
reel to reel. 



The Mission and the Challenge 

The mission 

You have probably heard the adage that "any experience that 
doesn't kill you is useful." This is perhaps more so in the high tech 
area, for here practically all new initiatives at cutting edge are 
extraordinarily susceptible to Murphy's Law. The major thesis of this 
paper is to illustrate how different pieces were put together to 
communicate content in a very coherent and powerful way. It was a 
journey intothe unknown, but we have made inroads. We began 
anexpedition that presented us with an alluring end state, a place of 
beauty and a place undreamed of only a few years ago in the 
information technology industry. But, we had no road maps, and we 
had very little resources. All that we were told was that there were 
tools existing all over the computing and information technology 
world. The new place we saw was the exciting world of interactive 
multimedia. There were several live demos to show that it is feasible, 
but more importantly that it is also necessary. Our mission and our 
challenge was not just to arrive at the enchanting land of multimedia, 
but also to use the medium for promotional purposes. We were 
charged with the mission of using such a technology to get across 
university ideas to a population base that was a moving target! 

You are probably asking by now what does the deluge of high 
technology have to do with a University Administrative Computing 
Department such as University Systems? It is unusual for a major 
university administrative computer processing organization to reflect 
upon these new technologies let alone get involved in using them to 
provide services. The multimedia project at The Ohio State University 
Systems started as a vision of President E. Gordon Gee who has now 
charged us with providing administrative computing services through 



the path of cutting edge technology. So, President Gee has already laid 
the foundation through which administrative computing can make a 
major technological leap into the twenty-first century! 

Such a group of services will be delivered by way of what shall be 
called "The University Front Door Systems" The two major attributes 
of the content of what we were charged to deliver were factual 
information about the university; and captivating and/or entertaining 
type of information. The part on factual information is intended to 
present the basic, yet, salient facts about the university. This is not 
merely a listing of statistical data, but the presentation of data in such a 
way that they are relevant to the visitor's or user's needs. Such things 
as the university's academic excellence, reputation and location, its 
faculty, staff, student life on and around campus, facilities, and cost are 
essential for both a potential student and his/her parents or guardians. 

The entertaining or captivating information was the more 
intriguing of the two types of information. It had a dual purpose. The 
first objective of such information is to seduce the systems' user. 
Essentially, this deals with the systems' delivery mode/s and interface 
design. If information is clearly depicted in graphical and easily 
understandable form, the user will find the system user-friendly. 
Additionally, information can be presented in a form that challenges 
the user's other skills, as in computer games. The second objective of 
captivating the user is to feature some or highlight some of what 
makes^e Ohio State University a highly reputable place. Thus, the 
information in this area will include both academic and non-academic 
achievements. 

The Challenge 

But while interactive multimedia holds so much potential, it 
does present enormous technical challenges. The challenge came with 
all the variables associated with developing any interactive 
multimedia system worth its salt. There was a shift for us, because 
rather than remain the "utility" data keepers of the university, we 
suddenly catapulted to different heights. We became engaged in 
marketing, image making - and oh well - artistry, video technology, 
photography script writing and much more in the artist's world, while 
remaining programmers, scientists and engineers! When you become, 
or are expected to become, all things to all people, you begin to wonder 
if anyone really took time to define your job Ascription. Recently, I 
came across one way the challenge can be explained. It stated, "you 
speak with many voices - the voice of the corporate executive who 
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wants performance and investment protection; the educator who is 
looking for economy and functionality; the sales rep who needs 
portability and ease of use; the engineer who demands performance, 
power and speed" (Z DIRECT, Zenith Data Systems, Summer 1992). 

In the block's world, the components of interactive multimedia 
are text, graphics, animation, audio and video. These monomedia are 
not simply bundled together. While a video source and the source for 
still images can be video cameras or VCRs, some knowledge of video 
and even lighting techniques may become necessary. This is a far cry 
from skills required, for example, to use animation to illustrate a 
complex subject. This requires not only animation skills, but also the 
skills of an artist. At that level, you will need to find more 
sophisticated software, one higher in sophistication than hypercard! 
You then move to color, only to find that the biggest challenge in 
having true electronic color intact is how to get from RGB to CMYK. 
"Any desktop publisher who's worked with color can tell you horror 
stories about colors that looked fine on screen but came back from the 
printer transfigured - greens that turned gray, blues that went purple, 
and flesh tones that developed a sudden case of jaundice... The culprit 
isn't the printshop. When it comes to color, you'll find scanners, 
monitors, and printers don't speak the same language, and when you 
try to communicate color information from one to another, something 
gets lost in the translation," Bruce Fraser, 1992. 

Then you move to data storage - if you scan one color image, you 
will need more than 2 megabytes of storage, which is more storage than 
you have on a single floppy disk. If you record one second of sound, 
you will need anywhere from 5 to 22 kilobytes. You, therefore, need 
more than one megabyte to store a good medium quality music that 
lasts for 45 seconds. So, to state the obvious - your multimedia data or 
information imposes enormous space requirements that worsen as 
more information or data is needed for updating. As the data 
increases, your space requirement increases exponentially. Well, e^ven 
if you have taken care of the data storage, you should be able to retrieve 
it when you want it with ease and fidelity. So, to retrieve your data you 
need to consider time - basically retrieval speed, based on your 
application. For data based issues alone the set of problems for 
multimedia, thus, include: one of storage, cost, access rate, data 
conversion, and data compression and decompression as well as 
reliability (based say on failure rate, static electricity and other ambient 
factors). 



To do anything to the movie, the movie must be moved from 
its analog source such as VCR or TV to the computer, and then be 
digitized say into QuickTime's Movie format. Among the Apple 
products required for capturing video from its source and digitizing it 
are SuperMac's VideoSpigot The editing products (once the movie is 
captured in the mac) are DiVA VideoShop and the Award-winning 
Adobe Premiere. Either can be used to "splice different sections of the 
digital film together, add titles, graphics or special effects." Other tools 
available can be used to animate any given QuickTime movie - 
something not possible with digital video. 



Our Experience and our Strategies 

What President Gee charged University Systems with on June 
14, 1991, therefore, was to develop a multi-media computer package 
prototype that uses a combination of high technology to reveal the 
essence of The Ohio State University as a leading institution for 
teaching, research, public service and much more. According to 
President Gee's Assistant John Elam, "The University Front Door 
Systems is one way to invite the visitor to explore this great university. 
Who is to say or measure all that we have lost in the way of funds or 
good students, simply because these people could not find a place to 
park, and did not know whom to ask nor where to get this 
information?" 

Any University Front Door Service must accommodate the 
caliber and interests of high school students and their parents and/or 
guardians whom The Ohio State wants to attract. It should challenge 
as it educates, it should attract as well as tell what makes this a great 
institution and one to choose. "We must be involved in the public 
schools to ensure that the students have high expectations of 
themselves and of the education they will receive at The Ohio State 
University," President Gee said. "We must challenge ourselves by 
bringing the best and the brightest students to our campus to engage us 
in intellectual dialog," he continued. This means that a Front Door 
system should enable the student/visitor to perform initial screening 
of why they are on campus, as well as proceed in the direction of 
interest to them. The person staffing such a place should have enough 
information about the university to support information from the 
system. Moreover, the person and the system acting in concert must be 
able to quickly provide specific and accurate solutions to the visitor's 
problems. For any visitor to make informed choices about 
opportunities and challenges at this university, and/or to make 
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subsequent decisions about attending, or about his or her ward 
attending Ohio State, he or she should be able to traverse the 
university easily by "On-Line" means and have at their finger tips, the 
immediacy and provision of their informational needs. 

University Front Door Systems Goals and Objectives 

There were two major types of goals to be achieved: one set of 
goals was targeted towards people, and the other was targeted to how 
technology reflected upon the university. Among some of the people's 
goals were: to provide a one-stop shopping center of all, that is The 
Ohio State University; to provide accelerated learning experience and 
personal profiles through an encapsulated Story of The Ohio State 
University; to provide needed visibility for the university to enable 
parents/guardians and potential students to make informed choices 
about college education for their wards/ themselves at The Ohio State 
University; to immerse and use all possible human senses in 
information processing, and present information in esthetically 
pleasing and easy to use fashion; and to provide a clearer picture of the 
essence of the university in forms which are readily communicable to 
the people of the State of Ohio and elsewhere. 

With regards to technology, some of the goals include those 
listed below: to show how technology is advancing higher education; to 
share and highlight the salient features of high technologies and the 
role of The Ohio State University; to use the large size of Ohio State as 
an advantage, by controlling and disseminating information in a less 
unwieldy fashion through the powerful medium of multimedia; to 
enable the quick redesign and presentation of current, sudden and 
unpredictable changes and conditions which affect the university; to 
remove/reduce built-in obsolescence in systems that are the first 
contacts a person makes with the university; and to consolidate and 
enable more efficient use of media resources available from diverse 
departments across the university. 

Strategies 

With these goals in mind, we articulated certain strategies that 
have seemed to be very helpful. We hope to share them with those of 
you who may be called upon to build such systems in the future. We 
began by evaluating and extracting meaning from the challenge. 

Strategy 1. Our first attempt was to interpret the vision. It is not 
often that staff in a university data processing department know and 
share a vision with the highest executive officer of the university. So 
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when President E. Gordon Gee shared some of his information 
technology visions with our unit, what was he saying - and more 
importantly what was he saying in the face of little or no budgetary 
backing? With such a rare type of support coming from the top, who 
could resist? The project soon gained broad base support because of its 
high visibility status. But as with most institutions of higher learning, 
Ohio State was feeling the budget crunch at the time. There was no 
money to build the dream system every one wanted! Meanwhile high 
support base and high visibility were translated immediately into the 
high cost of failure, and why the project must succeed. What v/ere our 
hopes? This led to other strategies. 

Strategy 2. - Form a high performance team which can cut 
mutually destructive contention and fragmentation, as well as reduce 
duplication of services. To strategize against the current tide, as well as 
expedite it, we had to locate existing resources on campus. Several 
campus units were requested to provide their expertise; and they did. 

Strategy 3. - Form partnerships with the different 
groups/departments and, thus, move more content into the jobs. But 
computing and information technologies and systems are islands with 
divided functions. University Systems' strategy has been one of 
joining forces with other departments where talents and resources exist 
for a combined or joint venture. University Systems is also devising 
innovative and more efficient ways of solving university 
data/information needs. 

Strategy 4. - Finally, we thought of continuity and obsolescence. 
We built shells that form the core of our systems. New systems are 
produced very fast because of this added value. 

To date, there are four University Front Door Systems, with the 
fourth currently on display on campus. Each system has improved 
upon its predecessor. The first UFDS is at the Center of Science and 
Industry. The second system was designed for Ameriflora, and the 
third system was displayed at the 1992 Ohio State Fair. As indicated by 
the statistics, letters and word of mouth, these systems have been very 
well received. I will demonstrate one UFDS conference. 



The promise 

What has been discussed here are basically "kiosks." They are 
stand alones. Connectivity will play a major role in the future, as more 
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and larger data bases become amenable to the techniques of 
multimedia through data compression and other techniques. 
Questions to be resolved may well range from what data types are 
available, and where they reside, to such basic needs as what does a 
modern information user want. .how can it be connected to what.. .at 
what speed.. ..in what form.. .for what purpose. ..and the list continues. 
Type of network - ethernet, Novell, Netware, Banyan, VINES, LAN, 
WAN - will then become a matter of choice, convenience and cost. 

No matter the value choices one makes now, one must leave 
enough room for growth because there will be the need to upgrade 
practically every hardware/software product/ tool in use. Interactive 
multimedia systems 1 tools are not yet in a mature market. Our own 
experiences have shown that we need to enhance performance, speed 
etc, so we have had to change processors, add memory, swap drives and 
so forth. In the future, we will need to build some connectivity with 
some form of high speed communications tools. Invariably, then, 
security will become a more pressing issue than we have so far 
encountered. 

The UFDS currently displayed Bricker Hall has a three 
dimensional "on-line" campus tour depicting major landmarks or 
major buildings on campus, and the services which are provided in 
such buildings. Such tours include, for instance, the Student Unions, 
the Towers harboring the Admission's, Fees and Deposits 1 , Financial- 
Aid^ and Registrar's Offices, the Medical complex, the stadium and the 
Wexner Center among others. 

Depending on whom you ask multimedia can be seen as "the 
harbinger of an era when computers will routinely convey 
information with sound and animation, as well as text images, and 
when television will become more interactive. But others see it as the 
victory of sound bites and flashy visuals over the printed word." (Jim 
Heid, MACWORLD, May, 1991, 225-232) 

Today, computers and televisions seem to be progressing toward 
a collision or convergence course. The forecast is that both home and 
business will soon arrive at the era of digital video communications - 
as more people become interested in actively interacting, exploring and 
playing the media as they deem fit, instead of sitting passively and 
absorbing whatever is communicated. This means the intersection of 
different media, technologies, and services that not too long ago were 
moving in diverse and variant paths. IBM and Time Warner are 
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currently negotiating to create an interactive television system. The 
success of this will allow Kaleida (formed by IBM and Apple) to tap into 
Time Warner's extensive cable business, its television business and its 
movie libraries. 

Think of the interest generated in how Hollywood and High 
Tech are generating conversations. Multimedia will be popping up on 
private FM bands, cable television stations, networks and (eventually) 
telephone lines. All these speculations are only the beginnings of what 
lies in store. Multimedia, especially in the interactive form, is will 
inspire more bewilderment and fascination. To illustrate the nature of 
this bewilderment and fascination let me just say a few words about 
virtual realities, as another promise of the future. 

Given virtual reality, we are able with either Data Gloves, full 
body DataSuits, or EyePhones to explore different types of three 
dimensional (3-D) spaces such as NASA's space station or the 
landscape of Mars (while still on earth of course) or climb Mount 
Everest within cyberspace. A person in this sort of world is engaged in 
what in current literature has been called "alternate realities," "meta 
realities," and "virtual realities," in which he or she engages in visual 
experiments which not only manipulate but even disobey natural laws, 
as we have understood them today. The name 'virtual means that it 
does not have any existence. So, "virtual reality" becomes an 
oxymoron - symbolizing a reality which is not real! Hence, those who 
participate in this new computer-defined world participate in abstract 
spaces called cyberspaces, within which exists neither the physical 
machine nor any physical viewer. The question, thus, is tantamount 
to this: if neither the viewer nor the physical machine has existence, 
then who is it that views what? I w r ill let you sleep over this one. 
Should you wake up and are still able to tell (where your mind is 
located in your body) you have completely missed the point! 



Conclusion 

Multimedia, interactive or not is not a substitute for other 
communication media. Rather, multimedia supplements traditional 
means of communication in a very powerful way. The power of 
interactive multimedia resides in its interactive and nonlinear mode 
of communication. (In fact, it does, by definition, render linear 
thought impossible). It is the closest thing to the natural forms of 
human interactive experience because it engages all the senses through 
audio, video (motion or still) animation, computer graphics and text. 
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What's more, the self propulsive nature of multimedia empowers the 
user, who can learn by digression in an enriched learning setting. 
Because of better representation of concepts, interactive multimedia 
becomes so potent it transforms a passive receiver of information into 
an active participant. To this end, it personalizes the information, 
stimulates thinking, and enables instantaneous discovery. Part of its 
mission in any institution of higher learning would be, beyond 
concepts, to communicate as vividly as possible how technology is 
advancing education. A byproduct of that may well be to entertain the 
user through this experience. 

Back to the point being made about virtual reality.. .remember... 
the point is the power and complexity of this artificial/virtual reality 
continues to extend the puzzle of what humans have since held to be 
reality. The easiest way to depict a similar medium is by holograms 
and stereopsis. It is not delusion. The puzzle of "virtual" or "artificial 
reality" forces us to challenge the current posit of what reality really is. 
Perhaps, we shall never know; this may well be the ultimate challenge 
- or at least part of the challenge. Interactive multimedia, on the other 
hand, is imbued with presence - in essence, it has reality! 
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Introduction 

As you know there has been quite a bit of discussion 
on the subject of "downsizing" or "rightsizing." I want to 
share with you an actual experience of downsizing. It is my 
hope that institutions that have similar circumstances to 
ours will be encouraged to proceed. For others, perhaps, 
there are some universal principles that could guide any 
size organization. Making dramatic changes to one's 
computer environment is a scary proposition. To change 
platforms, vendors, computer language, operating systems 
and trash all source code is not a fun thing to think 
about. Indeed, to alter the whole computer environment at 
one's campus is not an exercise for the faint hearted. 
However, with a blend of thinking, good fortune, and faith 
- dramatic positive results can be achieved. 

Historical Background of 
Computerization at DTS 

DTS History 

Dallas Theological was established in 1924 to train 
men to preach from the Bible (a unique concept in that 
day) . Because it is not affiliated with any particular 
denomination, the seminary was dependent upon voluntary 
gifts from individuals and churches. Obviously the Seminary 
had no computer Science department and the leadership of 
the school in many cases did not even know how to use a 
keyboard. 

Using The Service Bureau 

In the early 1980' s there was a need for increased 
gift income. At that time the Seminary contracted with a 
service bureau to provide a computer assisted "direct mail" 
Fund Raising system. This system was written in Cobol/CICS 
and utilized an IBM 4341 mainframe computer. 

The major application was a Direct Mail Fund 
Raising/Donor Management system. There eventually came to 
be over 400,000 names in the data base. There v/as also a 
System 3 which was used to produce letters that had a 



personal look. The system also sent thank you letters for 
all gifts received. In the early eighties, Dallas Seminary 
was the leader in personalized direct mail in our market. 

The service bureau also began to code some Accounting 
programs for the Seminary. These programs were never 
completely finished . They provided some limited accounting 
reports but were filled with bugs. 



Bankruptcy Scenario 

In 1983, the service bureau began to have financial 
difficulties. The Seminary decided to purchase the System 
(hardware and software) and move it onto the campus. Since 
the Seminary had become completely dependent upon the 
services that this system provided, they really had very 
little choice but to obtain the system. Basically all of 
the donor and financial information resided upon this 
system. 



Summary 

The institution had become financially dependent upon 
the services of a system that required the use of programs 
written in COBOL/CICS on an IBM 4341 Mainframe operated by 
an external service bureau (outsourcing) . As a result of 
the service bureau ' s f inane ial difficulty , overnight the 
Seminary inherited a Data Processing Department without the 
benefit of careful planning or counting the cost. 

Experience Using the Mainframe 



Expectation problem. 



With the arrival of a powerful computer on campus, the 
staff and faculty began to expect immediate benefit . 
However, the system was only capable of servicing the basic 
fundraising needs of the Seminary. 



Leadership problem. 

The Seminary had no expertise in the field of data 
processing and no one knew anything about utilizing a 
computer for any campus operations. As a result the 
Seminary turned the department over to a student with no 
data processing experience. 



Partially as a result of increasing pressure to 
utilize the capabilities of this computer the Seminary 
decided to automate the Registrar's office. But, because of 
lack of experience, they selected a system that was 
completely incompatible with the original system. The 
Registration system required the data base system DLl while 
the original fund raising system used VSAM files. 
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Expense problem. 



In the mid 1980 ' s financial pressures began to mount 
at the Seminary. During this time the cost of ownership of 
the Mainframe continued to., increase primarily due to the 
increased cost of maintenance which had reached over 
$112,000/yr . 

There were additional increases in costs related to 
the need for hiring additional staff to handle the 
necessary fixes and enhancements to the various systems. 
Even with additional staffing it was difficult to respond 
to the many requests for computer service. 

The PC Problem. 

During this same time period there arose an increasing 
demand for personal computers. Departments were discovering 
the value of using PC's for word processing and a few 
departments tried to automate some of their processes using 
dBase software and other similar programs. This 
proliferation of personal computers added additional 
support requirements to an already overwhelmed department. 

New Leadership 

With the growing frustration and confusion concerning 
computer technology, the Seminary hired the author of this 
paper to try and solve the problem. 



With the presence of this powerful mainframe computer, 
people began to expect to have automation available to aid 
them in their assigned tasks. However, the computer 
services department was not able to provide support within 
the cost parameters, so departments began to try to use 
PC's and Macintoshes to meet their data processing needs. 



As a result of the aforementioned circumstances the 
situation became quite intolerable, especially with the 
increasing financial pressure. It was clear that there had 
to b'- better solution to the Seminary's automation needs. 
The problems could be summarized as follows: 

1. The current mainframe system was TOO COSTLY. The 
high software maintenance fee, the increasing hardware 
maintenance expense, and the increased staffing costs had 
become prohibitive. 



Summary 
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2. The current mainframe system was TOO UNRESPONSIVE. 
It had become simply too time consuming and labor intensive 
to keep up with the programming changes that were 
continually required. 

3. The current mainframe system was TOO ISOLATED . The 
multiplication of stand alone PC Systems which lacked any 
consistent integration of data had produced a rather 
confusing state of affairs. 

Summary 

The mainframe computer environment that was inherited 
from the Service Bureau was incapable of providing the 
comprehensive computer service that was needed. The 
mainframe computer was costly, unresponsive and isolated. 

The Search for a Solution 

When these facts became distressingly clear, the 
decision was made in January of 1987 to find a new solution 
by January of 1988. 

The Experiment 

It was about this time that the industry became 
enamored with Local Area Networks. We installed a small 
Novell LAN in our office to experiment v/ith the 
possibilities. It was clear immediately that this 
technology was too immature to handle the demands of a 
school our size. Also, there was no existing software 
available that would have been capable of handling our 
requirements . 

The Consultation 

During this time I asked IBM to give us a 
recommendation as to what we should do in this situation. 
Their support team came up with quite different scenarios. 

The first was to upgrade our 4341 to a 9370. This 
solution really did not improve our situation since it did 
not address our fundamental problems. 

The second possibility was to convert to a Token Ring 
LAN. However, again there was no software available for our 
application . 

The third option was to combine a mini -computer 
(System 36) with the LAN . There was a software package 
available on the System 36 but it was written in RPG II on 
this aging platform. 
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The point is that our consultation with IBM , 
unfortunately, did not produce a solution that addressed 
our concerns. It was obvious that any solution would have 
to involve a completely different system from any that our 
trusted primary vendor was suggesting. 

The Consultant 

During this time the administration was growing in 
their frustration at the inadequacies of the computer 
system. Therefore, the administration hired a consultant to 
evaluate the situation. The consultant concluded that a 
mini-computer was most appropriate for DTS but there was 
uncertainty about which one or what software might work in 
our situation . 

The Criteria for Software 

After all of these conflicting and confusing sources 
of information, time was racing by. It was now clear that 
we would have to find a so v, tion with our own ingenuity and 
we would not be able to depend entirely upon the advise of 
the "so-called" experts. The first step was to locate the 
software around which we could build our system. 

From previous experience and research, it seemed clear 
that any software solution would have to meet the following 
requirements : 

1. The Software would have to have a relational data 
base with flexibility and expandability. 

2. The system would have to have non proprietary 
Operating System, language, and hardware. 

3 . The system would have to handle • both the 
Administrative Applications and Library Automation on one 
platform. 

A little Providence 

Providentially, a computer consultant in the field of 
educat ion happened to visit the school on other business . 
This consultant was asked almost off handedly if he was 
familiar with any software systems that might handle the 
Seminary's needs. He just happened to have been recently 
hired to evaluate administrative computer systems. He was 
able to give the name of the system that was highest rated 
in his research. The problem was that the software was only 
available on hardware platforms that were rather expensive 
and somewhat out of date. And, the hardware vendor really 
did not have the reputation for service that instilled 
confidence . 
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Again, providentially the treasurer of the seminary 
received a letter from a particular vendor that announced 
the software mentioned above had just been ported to their 
hardware platform. That combination of excellent software 
combined with an excellent vendor seemed to provide an 
ideal solution to our needs. 

The system we were considering was built upon the UNIX 
platform. The assistant librarian was assigned the task of 
locating any library systems that would run on this 
particular UNIX platform. He was able to locate just one 
library system that would run on this emerging platform. 

At about the same time it was learned that a school 
similar to DTS had just completed an extensive survey of 
several campus administrative systems. This school had 
concluded that the vendor and platform that had attracted 
our attention was the best solution for them. 

A Problem 

The only real problem was that the library system was 
not the one that the library staff really preferred. They 
were also skeptical of having both the administrative and 
library systems on the same CPU. They had heard from other 
sources that this always leads to conflicts in priorities 
and performance problems. To some extent their concerns 
were valid. 

The Decision 

The final decision however, rested in large part upon 
the fact that the cost of the proposed system could be 
handled with the same annual expenditures as the current 
budget. For an initial cost of $540,000 the Seminary could 
have a total automation system for the campus. 

Summary 

The process of procuring the system had a mixture of a 
little wisdom, a little providence, and a little faith. 

The Conversion 

In order to "pull the plug" on the mainframe, it would 
be necessary to convert the four primary mainframe systems 
to the new system. I had originally assumed that we would 
need to run some parallel operation for up to six months. 
We actually turned off the mainframe in less than three 
months ! 
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Timing 



The system was delivered June 3, 1988. In order to 
minimize the dual operation it was essential that the 
financial modules be in operation by the beginning of the 
fiscal year which was less than one month away. To meet 
this deadline we utilized the conversion support from our 
vendor primarily to assist in the implementation of the 
accounting system. It was decided not to carry forward any 
of the accounting system detail into the new system. The 
controller determined that he could enter the previous 
years totals manually and that the detail would not be 
absolutely necessary. With excellent support from the 
vendor we met the target date of July 1, 1988. 

The next system to be installed was the Direct Mail 
Fundraising system which was the most complicated. It 
required reproducing in function a great deal of Cobol/CICS 
code by using the Relational Data Base tools and converting 
the data from IBM VSAM into the new RDBMS . In this effort 
we were assisted again by the vendor as part of the overall 
cost of the system, and we even had one of their 
programmers work with us on site for two weeks. Also, one 
of our staff programmers wrote programs to convert the 
information directly from the mainframe data using magnetic 
tape as the transport. The complete fundraising system was 
converted and operational in August of 1988. 

The software vendor had indicated that it was probably 
impossible to convert the student academic data directly 
and that we should plan on reentering all of the transcript 
and course data. The rekeying of data sounded like a 
nightmarish task to my staff so one of the programmers took 
it as a challenge and actually wrote routines to handle the 
conversion of the data which went smoothly. We handled Fall 
registration in September of 1988, exactly on schedule. 

Training 

The training for the current Computer Services Staff 
was handled with remote training by the vendor at his site. 

The training of on campus users was done primarily by 
the computer center staff. That training was "on the job 
training" for the most part. For example the gift entry 
personnel were began using the new system on a Monday 
morning when we realized that there was no real reason not 
to proceed. 
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Sale of Mainframe 



Since there was not much of a market for the 
mainframe, we considered selling "Sledge Hammer Blows" in 
the parking lot for frustrated computer users* The idea was 
to get the new vendor to pay us to do it, then get IBM to 
pay more for us not to do it. However, this plan was not 
implemented. We sold the IBM mainframe and peripherals for 
$2,500. 

Summary 

The keys to our remarkable success in converting so 
rapidly and smoothly were: 

1. Staff Excellence. The in house staff were of 
excellent quality and were highly motivated to accomplish 
the transition to newer more useful systems. 

2. Quality Vendors. All of the vendors involved 
performed well in their respective areas. 

3. An Enthusiastic and supportive controller. Because 
the success of the installation would be measured in large 
measure by the perception of the quality of the financial 
modules by the controller and ultimately by the board, 
having the controller as a partner in this project was 
extremely important to the success of the venture. 

The Results 

The results of downsizing from the mainframe to the 
minicomputer have been extremely positive and quite 
dramatic. The campus has undergone a revolutionary 
transformation with the arrival of full automation. 

Improved use by customers 

The use of computer technology by the various 
departments on the campus increased dramatically. In 1985, 
only four departments were using computer applications on 
the mainframe with a user base of 33. Today, the number of 
users has increased to 152 users in 30 different 
departments . See Chart 3 . 

Distributed processing 

The mainframe computer was primarily a "batch" 

oriented system but the new system puts the computer 

operation into the hands of the user so that he controls 
his own work flow including printing. 
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Reduced Staffing Requirements 



The staff required to handle the drastically increased 
load has been reduced steadily over the years. In 1985-86 
there were 22.5 FTE directly involved with the computer 
operation including Data Entry, today there are 13.25 FTE. 
See Charts 1, 2 and 4.. 

Reduced costs 

Hardware and software maintenance costs have been 
reduced from over $112,000 to $61,000 which now includes 
the entire campus including the library. See Chart 4. 

Reliability 

The new system is easier to maintain. It never crashes 
as CICS did regularly. 

Expandability 

With flexibility and ease of use of the relational 
data base tools, there is a powerful ability to continually 
do more with less. New user defined systems are generally 
quite easy to create. A number of special systems for 
departments have been produced to handle funccions that 
were not provided a vendor written module. 

Conclusion 

Our downsizing experience was a fantastic success when 
measured by increased service with less cost. The key 
components in our experience of successful downsizing were : 

A Little Wisdom: 

1. R&D - We did do R & D to get first hand experience 
with some of the technology. 

2. Vendor - We did consult our vendor. 

3. Consultation - We did consult a consultant. 

4. Software - We did concentrate on identifying the 
appropriate software for our environment. We recognized 
that selection of software was the most important component 
of the decision, not hardware. The software had to be 
flexible, expandable, and portable. 

A Little Providence 

1. The Report - Someone had recently done research in 
this area. 
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2. The Alliance - The software vendor of choice had 
just ported to a superior platform. 



A Little Faith: 

1. In Staff for successful conversion. 

2. In Vendor (but not blind faith) 

3. In Self (Experience, you know what you know!) 

Summary 

To change platforms, vendors, computer language, 
operating systems and trash all source code is not a £un 
thing to think about. Indeed, to alter the vfix&Le compi/ter 
environment at one's campus is not an exefcise fori the 
faint hearted. However, with a reasonable ^lend off' some 
thinking, good fortune, and faith - drama\dc positive 
results can be achieved. ^sf* 



1985-86 

Computer Resource Cost and Allocation 



Total Computerization Costs = 
Seminary E&G Costs= 
Computer Costs = 



$826,241 
$8,959,084 
9.2% of G&E 



FTE = 22.5 



Computer Cost Allocation 1985-86 




■ People 
E3 Equip 

■ Software 
□ Other 

O Payment 



49.2% 
19.2% 
5.3% 
5.3% 
21.0% 



Computer Resource Utilization 1985-86 




■ Fund Raising 

□ Financials 

M Student Records 

□ Alumni 



78.0% 
11.0% 
8.0% 
3.0% 



Chart 1 
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1992-93 

Mini-Computer Resource Allocation 



Total Computer Costs= $701,423 FTE = 10.5 

Seminary E&G Costs= $10,374,933 
Computer Costs = 6.8% of G&E 

Computer Cost Allocation 1992-93 




■ People 57.6% 

□ Equip 13.2% 

■ Software 17.0% 

□ Other 1.6% 
M Payment 10.5% 



Computer Resource Utilization 1992-93 




Chart 2 



GROWTH IN COMPUTERIZATION AT DTS 



Growth in Computerization 




84-85 85-86 86-87 87-88 89-89 89-90 90-91 91-92 92-93 

Fiscal Year 

o Departments n Applications 
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I . INTRODUCTION 



ABOUT THE UNIVERSITY 

Rutgers, The State University of New Jersey, with over 47,000 
students on campuses in Camden, Newark, and New Brunswick, is one 
of the major state university systems in the nation. Tne 
University comprises twenty- six degree -granting divisions; twelve 
undergraduate colleges, eleven graduate schools, and three schools 
offering both undergraduate and graduate degrees. Five are located 
in Camden, seven in Newark, and fourteen in New Brunswick. 

Today; Rutgers continues to grow, both in its facilities and 
in the variety and depth of its educational and research programs. 
The University's goals for the future include the continued 
provision of the highest quality undergraduate _ and graduate 
education along with increased support for outstanding research to 
meet the needs of society and fulfill Rutgers' role as The State 
University of New Jersey. 
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ABOUT RUCS (RUTGERS UNIVERSITY COMPUTING SERVICES) 

RUCS (Rutgers University Computing Services) was established 
in 1990 by merging the CCIS (Center For Computing and Information 
Systems) and the CCMS (Center for Computing and Management 
Systems) . CCIS was primarily responsible for providing support to 
the academic community within the university. Ic supported the 
instructional and research functions throughout the Rutqers 
community. CCMS was responsible for providing support to " the 
administrative community within the university, it was responsible 
for the planning, development, and maintenance of computerized 
systems which support administrative functions throughout the 
Rutgers community. This restructuring took place to reduce 
redundancy and allow a focus on functions. 

RUCS (Rutgers University Computing Services) currently 
comprises seven divisions: 

USER SERVICES DIVISION is the "front Door" to University 
computing and electronic information resources for the Rutgers 
community and, as such, is also the Computing Services 
advocate for our users, both academic and administrative. 
User Services is made up of the following units: 
° PandA (Publications and Accounts) is responsible for the 
setup of accounts on all of the computers within RUCS, 
coordinating the publications and documentation related 
to these computers, publishing the RUCS Newsletter, and 
more. 

o The Information Center is a central office staffed by 
RUCS personnel designed to answer user questions. For 
questions that cannot be answered by Information Center 
personnel, the user is referred to the appropriate 
department and/or individual to answer their question. 

o The Software Consulting Unit is responsible for 
Super computing at Rutgers University, Statistical 
Software Packages, Machine Readable Data Files, CWIS 
(Campus Wide Information System) , E-Mail support and 
training, User ad- hoc requests, data downloading, and 
more. 

o The Microcomputer Consulting Unit assists users with PC 
based systems and applications. This group consults with 
users to determine the hardware and software best 
suitable to satisfy users' needs. 

o The Campus Computing Facilities unit is responsible for 
the general and special access computer locations 
throughout Rutgers on the various campuses, 

° The Educational Programs unit prepares and presents 
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courses on a wide variety of topics relevant to data 
processing at Rutgers University. 

ADMINISTRATIVE SERVICES DIVISION is responsible for 
administrative computing systems which support the Rutgers 
community, such as student records , student services , 
accounting, payroll, and more. This division is divided into 
three departments; Educational Systems Administrative Systems, 
and Data Base Administration. Educational Systems include 
SIMS (Student Information Management Systems) , Graduate 
Admissions, Undergraduate Admissions, Institutional Research, 
Student Health, Faculty Survey, Library, Scheduling and Space 
Management, Financial Aid, and more. Administrative Systems 
include Student Accounts Receivable, Payroll and Personnel 
Services , Accounting and Budgeting, Accounts Payable, 
Purchasing, and more. Data Base Administration is responsible 
for coordinating and maintaining the IMS data bases of both 
the Educational and Administrative Systems departments. 

TELECOMMUNICATIONS DIVISION encompasses voice and data 
communications for the Newark, Camden, and New Brunswick 
campuses including the operation of the RUNet (the Rutgers 
network) . This division is composed of the following 
departments; Network Operations, Engineering and Design, 
Network Services, Voice Services, Network Equipment 
Installation, and Network Equipment Repair. 

CAMDEN COMPUTING SERVICES and NEWARK COMPUTING SERVICES 
DIVISIONS support their respective computing communities and 
are the first point of contact for their academic and 
administrative needs, including; microcomputing, high- 
performance computing, and networking. 

OPERATIONS AND TECHNICAL SUPPORT DIVISION provides, maintains 
and operates the host computer facilities on the New Brunswick 
Campus which process Rutgers academic and administrative 
applications respectively for University departments, faculty, 
staff, and students. This division is made up of three 
departments; Administrative Systems Operations, Educational 
Systems Operations, and Technical Services supporting the IBM 
and VAX computing environments within the first two 
departments . 

NETWORK RESEARCH/ LCSR DIVISION is responsible for providing 
services to specific research groups including the LCSR 
(Laboratory for Computer Science Research) , the Center for 
Discrete Mathematics, instructional support for the New 
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Brunswick Computer Science Department, and other special 
projects . 
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RUCS currently maintains a variety of computing systems from 
a variety of vendors to support the needs of the Rutgers community. 
An IBM 3081 running MVS and Super Wylbur, a cluster of DEC VAX 
8650' s running VMS, and a SUN Sparc Station running UNIX are 
available to support the academic community. An IBM ES/9000 
running MVS/XA supports the administrative community with over 700 
devices in 39 buildings using standard IBM technology. Numerous 
Apple, IBM, IBM clone microcomputer systems, and SUN workstations 
exist in departments throughout the University providing for 
specialized departmental needs. 

The public network known as RUNet (Rutgers University Network) 
has connections to all the international networks, is used heavily 
by thousands of faculty, staff, and students, and is based 
primarily on the open non-proprietary protocol TCP/IP. Over the 
last few years significant growth has occurred in RUNet through the 
commitment of University resources to permit construction of a 
fiber-optic backbone cable plant on several Rutgers campuses, 
resulting in the direct interconnection of sixty (60) buildings. 
In addition, over two hundred (200) dial-in ports are available 
into RUNet. RUNet currently links thousands of computers through 
the interconnection of one hundred and twelve (112) TCP/IP subnets, 
twenty- one (21) DECnet regions, nineteen (19) Novell local area 
networks, and ninety- seven (97) Appletalk zones, all of which 
provide services to academic and potential administrative systems 
end users. In addition to the networks now linked by RUNet, there 
are twenty- one (21) isolated Novell networks awaiting connections 
to RUNet. 



RUCS continues to improve and build upon the numerous services 
offered. We are dedicated to strengthening the level of support 
for faculty, students, administrators, and staff as they use 
computing and electronic information resources. 
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II. BACKGROUND 

(How we got where we are today - a historical perspective) 
ABOUT OUR USERS 

As the number of faculty, students, and staff accessing the 
University's systems grew, it became evident that there were 
different types of users, especially in the administrative 
computing area. These types of users have been loosely categorized 
as : 

CLIENTS - Clients are the people for whom particular 
application systems have been developed. They are the prime 
users and/or custodians of, and are responsible for, the data 
contained within these systems. For example, the Office of 
the Registrar is a client and the Student Registration System 
is the application used by this office. Client staff are 
intimately familiar with their systems and work closely with 
their assigned project teams from the Administrative Services 
Division of Computing Services to enhance, modify, and 
document these systems. 

END USERS - End Users are people who have a need to work 
with the information contained within certain application 
systems. End Users may or may not be intimately familiar with 
the application systems they need to access. For example, a 
department chair desiring class roster information from the 
Student Registration System is an End User. In the End User 
areas, there were a variety of procedures in place to access 
and process information, such as: 

direct access to the mainframe system and its 
applications via hard- wired connections, 
access to the mainframe system and its applications via 
RUNet , 

dial-up access to the mainframe system and its 
applications, 

departmental "Shadow" systems where the departments in 
question effectively process their own data a second 
time, and 

an ad-hoc request procedure for special reporting and/or 
processing requests . 

Typically, End User requests were received for reports and/or 
functions that were not currently available within existing 
application functions. These requests would be channeled to the 
project teams responsible for the particular application to be 
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fulfilled. Frequently, the request could be handled via Mark IV, 
a product from Sterling Software designed for quick report 
generation. When this was not possible, a third generation 
language program (COBOL) had to be developed. Depending on the 
workload of the project team and the complexity of the task, turn 
around time from request to delivery of the final report or 
function ranged from a few days to a few weeks to even longer. The 
same scenario also held true for Data Download requests. This 
situation presented an extraordinary opportunity for improvement. 



ABOUT USER NEEDS 

With thousands of users in these areas, learning user needs 
and communicating activities and upcoming events became of 
paramount importance. Clients and End Users were actively 
solicited to take part in RUCS' efforts to improve services. .In 
199 0, RUCS initiated a University-wide study to determine how we 
were perceived and how we might best improve service to this 
community. The study queried Clients and End Users throughout the 
University. One specific area that stood out in the majority of 
the responses was IMPROVED ACCESS TO ADMINISTRATIVE DATA. Many 
respondents expressed a desire to access and/or download data 
currently collected and stored in the Administrative Systems 
Division's mainframe computer in a timely manner. Data downloading 
capability was viewed as a way to reduce the potential for data 
entry errors when data was entered a "second" time into 
departmental systems. The data desired included: Student, Payroll, 
Accounting, Budgetary information, and more. Providing a USER 
FRIENDLY means of access was another point frequently mentioned* 



THE SEARCH FOR A SOLUTION 

In response to this survey, RUCS formed an on- going committee 
to study ways to improve access to administrative data* This 
Distributed Data Base Committee enlisted the aid of many areas in 
the University community at large to determine the best approach to 
accessing and downloading Administrative Data. 

One issue of concern to all involved was security. In a 
separate study, the RUCS Security Review Committee reviewed network 
history, the administrative computing environment, and possible 
network security risks. This committee then recommended new 
technology in the form of non- reusable password technology for 
users accessing administrative data from any segment of the network 
(RUNet) . This technology involves mainframe software on the host 
and the purchase of a device similar to a credit- card by network 
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users. This device displays a non-repeating number that is 
coordinated with the user's account on the mainframe. In addition 
to this new technology, the committee recommended new procedures to 
complement this technology. New sign-on screens and procedures 
were developed . 

The Distributed Data Base Committee recommended a two-phased 
approach for improving data access for End Users. The first phase 
would be to improve the selection of administrative data and the 
eventual downloading of that data to the End User workstation. The 
second phase will require the addition of distributed database 
software both for the mainframe (server) and personal computer or 
workstation (client) . This paper will deal with events related to 
Phase I . 

The Distributed Data Base Committee created a Task Force which 
completed a preliminary evaluation of products designed 
specifically for downloading mainframe data to personal computers. 
The Task Force selected five (5) products for further review. 
Vendors of these products were contacted and a series of in- house 
demonstrations were arranged. Clients and End Users were active 
participants in these demonstrations. The Distributed Data Base 
Committee compiled detailed evaluations of these products 
culminating with the recommendation to purchase Answer/DB and Micro 
Answer II from Sterling Software. 



THE CHOSEN SOLUTION 

Answer/DB and Micro Answer II are companion products . 
Answer/DB runs on the mainframe computer and is used to generate 
ad-hoc queries and reports. This product offers the End User a 
simplified lead-through style of operation based on the information 
that the End User is permitted to see. Conceptually it is very 
similar to the Mark IV product already installed except that 
Answer/DB is completely MENU DRIVEN and USER FRIENDLY. Requests 
submitted by Answer/DB are stored in a holding file for subsequent 
processing by an Extractor/Processor. These Extractor/Processors 
are run daily at scheduled intervals. As the Extractor/Processors 
run, they process all currently outstanding queries and produce 
output that is placed back into the same holding file as the 
original request. This output is now available for review and/or 
printing by the requesting user the next time they access the 
system. 

Micro Answer II runs on an IBM PC or any clone. It is 
designed to be a "front end" for the Answer/DB product. 
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Information concerning data areas that can be accessed by a 
particular \iser is first downloaded to the PC from the mainframe. 
Once this query and data access permission information has been 
downloaded to the PC, the user can create queries for submission 
while working off-line on their PC. These queries can be submitted 
for subsequent viewing and/or downloading. Like Answer/DB, Micro | 
Answer II is MENU DRIVEN and USER FRIENDLY, Once queries have been " 
created, the user can sign on to the mainframe to upload their 
query into the same holding file used for Answer/DB requests. The 
Extractor/Processors then handle the Micro Answer II requests in 
the same manner as they handle Answer/DB requests; placing 
completed requests back into the holding file. Once completed, 
Micro Answer II allows the user to download the retrieved data to 
the PC, Once the data has been retrieved to the PC, it can be 
converted to one or several formats. There formats include; ASCII, 
Lotus 1-2-3, Lotus Symphony, dBASE, DIF, and more. 
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III . IMPLEMENTATION 



STAFFING 

Due to several retirements within RUCS, it was possible to 
realign personnel lines so that an application project team of 
three people could be created within the Software Consulting Unit 
of the User Services Division, The team consisted of two 
Programmer Analysts led by one Senior Programmer Analyst. All 
three of these positions were filled by new hires- One Programmer 
Analyst came from within the University while the other two 
positions were filled from outside the University. With staffing 
levels completed, the new team (which came to be known as THE "A" 
TEAM) underwent vendor training to become on-site coordinators of 
the products. Additional responsibilities of the "A" Team include; 
developing and teaching courses on E-Mail, JCL, and other topics as 
necessary; fulfilling End User ad-hoc requests; developing 
documentation on applicable software products and procedures for 
PandA; and more. 



PROJECT OVERSIGHT 

The Distributed Data Base Committee formed two sub- committees 
to oversee the implementation of the product. A Distributed Data 
Steering Committee was charged with identification of issues 
relating to the larger University community, communications with 
the University community, and oversight of the implementation. 
This committee was composed of representatives from various 
disciplines and departments within the University. The Distributed 
Data Steering Committee prepared an announcement of the decision to 
purchase the product to facilitate data access and asked for 
volunteers to become Pilot Users of the new product. 

The Distributed Data Steering Committee identified several 
tasks it deemed important for the success of the implementation. 
First was the issue of managing user expectations. Early on, we 
realized that the success of this project relied heavily on how 
users perceived this new service. The Steering Committee decided 
to pursue a marketing strategy when describing the new methods to 
end users. Relative comparisons were made between the current lead 
times for fulfilling End User requests for new reports and the 
anticipated lead times via the new method. This aspect was 
important because while the new method entailed lead times of 
several hours, the old lead times were often days and sometimes 
weeks . 
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A Distributed Data Implementation Committee was charged with 
the actual product implementation. This committee received 
guidance from the Distributed Data Steering Committee. This 
Distributed ^ Data Implementation Committee was composed of 
representatives of the various divisions within RUCS that were 
responsible for the operation and processing of the Administrative 
Systems . 



The Distributed Data Steering Committee suggested a phased 
approach for the Distributed Data Implementation Committee to 
follow. This approach consisted of three phases. Phase I was to 
involve the use of three (3) pilot users, Phase II was to encompass 
ten ( (10) pilot users, and Phase III would provide general 
availability of the product to the University community. With 
guidance from the Distributed Data Implementation Committee, the 
"A" Team was given responsibility for the initial implementation of 
the pilots and for the general release or "roll out" of the 
product . 

Following a classic Project Team Approach, the "A" Team set 
about implementing two internal pilots and one external pilot. The 
team's ability to focus on the task at hand and provide a central 
organization to act as a clearing house for all aspects of the 
implementation was an advantage. Periodic status updates to the 
Distributed Data Base Implementation Committee helped keep the 
project team aware of the concerns and issues of all of the 
operational areas involved. The first task for the "A" Team was to 
develop a list of tasks required for the implementation of all 
three phases and to put that task list into a logical project plan 
complete with time estimates for completion. The team made 
judicious use of a PC based project tracking software package to 
build the Project Plan, track its progress and report that progress 
to the committees on a periodic basis. The second task for the "A" 
Team was to develop a set of standards to be used during the 
implementation. These standards dealt with naming conventions, 
rules for creating security access profiles, formats for the on- 
line "help" texts associated with each data field accessed, and 
more . 



Once the project standards had been set, work could begin. 
Major activities within the project plan included the following: 
o meeting with potential pilots to review their 

requirements and identify their needs, 
o selecting pilots based on their needs, 

o building data definitions for the data to be accessed, 
o testing the data definitions in actual use with the 
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product , : 
o building help descriptions for each data field within 

each data definition, 
o testing the implementation of the help descriptions, 
o establishing automated procedures for uploading the help 

descriptions to the data definitions, 
o building individual profiles for users of the system, 
o establishing automated procedures for uploading the 

profiles from a masted ^fdle so that security could be 

easily maintained, 
o conducting on-site installation and training for the 

initial products in the use of :he product, and 
o more. . . 

As the "A" Team progressed, other operational areas were 
gradually involved. This method allowed the "A" Team to lay the 
groundwork for the implementation and bring other technical areas 
into the loop prior to any production release. 

The "A" Team initially completed three (3) pilots in a test 
mode. This concluded Phase I as previously identified. Two of 
these pilots were internal to RUCS and the third was an outside 
user. The second phase of pilots consisted of seven (7) outside 
users from various areas within the University. These pilots were 
selected from those that had volunteered in response to the 
announcement from the Distributed Data Base Steering Committee and 
were phased in based on the specific areas of information that they 
required. 

The "A" Team chose to build the data definitions for the most 
widely used data bases first. Pilots were then added based on 
their requirements to access this data. As more pilots were 
selected, more data bases were defined to meet their needs. With 
the completion of the individual data definitions for the most 
widely used data bases, it was then possible to build definitions 
for LOGICAL DATA VIEWS that combined data from two or more areas 
that could be presented singularly to the users. ^ It became an 
evolving process with the managed addition of pilots and data 
definitions to foster a smooth implementation. This technique 
enabled the "A" Team to build data definitions in an organized 
manner that provided maximum response to "end user" needs. 
Concurrently with the building of the data definitions, the "A" 
Team was also working closely with the Security Office to build 
proper user profiles that would protect the confidentiality of the 
data while allowing the access to information that the users were 
entitled to. 
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As Phase I was being completed, the team was also developing 
formal installation materials, documentation, training materials 
and courses. These items were developed with input from the pilots 
and in conjunction with the appropriate areas within the User 
Services Division of RUCS, particularly PandA and the Educational 
Programs Unit. 

As with any major project of this magnitude, we were not 
without our share of problems. However, the vendor, Sterling 
Software, was ever ready, willing, and able to assist us. Their 
800 help line was invaluable. In addition, the supporting groups 
within RUCS Operations and Technical Support and RUCS 
Administrative Services were instrumental in easing the new 
products into the every day world within Rutgers. 



WHERE WE ARE TODAY 

Today, we have successfully created data definitions for all 
of the critical Data Bases in use at Rutgers. In addition, we have 
created definitions for several of the lesser used areas. RUCS has 
developed training sessions to teach the use of Answer/DB and Micro 
Answer II and we have many users actively querying and downloading 
data daily. This project has become an EVOLVING PROCESS that is 
opening more and more areas to user access every day. 
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IV. 



THE FUTURE 



WHERE WE'RE GOING FROM HERE 

The search continues for an enterprise solution that will take 
us to a truly distributed processing environment with owners of 
data directly responsible for its entry and content. 

RUCS will continue to work with the University Community to 
develop and prepare a long-term data base strategy for the 
University which a successor group will implement, taking into 
account the virtues of relational and client/server architectures, 
distributed computing, workstation capacities, and vendor and 
market developments . 

RUCS will use investigative and decision-making processes to 
inform the University community about data base technologies and 
potentials, and to develop RUCS staff skills and knowledge. 

RUCS will involve appropriate users and user groups in the 
investigations and recommendations. Provosts and vice presidents 
will be asked to suggest appropriate audiences and participants. 

RUCS will promote the need for ancillary policies which need 
to be developed by other appropriate University bodies, e.g. an 
administrative information access policy, and an information 
security policy. WE'LL NEED A WELL DEFINED ACCESS POLICY. We'll 
need a policy stating disclaimers associated with all data provided 
by various areas. This is especially true in the case where one 
area receives data from another and then embellishes it to provide 
more detailed information. "End Users" of this second generation 
data have the right to know its age and original source as well as 
any subsequent additions, updates, and/or special circumstances 
that may apply. 
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V. CONCLUSION 

While there is much to be done to complete the long range plan 
to provide greater access to administrative data to End Users, much 
has been successfully accomplished. If there is one overriding 
reason for this success, it has been the INVOLVEMENT and 
COOPERATION of the Clients and End Users throughout the life of 
this project. Kudos to our users and for the efforts they have put 
forth to make this a successful project. Our users are our 
customers, and OUR CUSTOMERS ARE FIRST RATE. 
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This presentation will show how The Ohio State University used McMcnamin & Palmer's 
Event/Response technique as an alternative to functional decomposition to extract essential 
requirements for a system. University Systems at The Ohio State University is responsible for 
administrative computing for the entire University community. Therefore we did not develop 
our process as a research project; rather our reasons were very practical. Our accomplishment 
demonstrates what can he achieved with sincere management support and pro-active people 
working toward a similar goal with very limited resources. Because of the personal dedication 
and determination of tiic people involved, we now have a pn>cess we not only feel comfortable 
with, but we also feel is a very practical solution. 

The technique begins with defining the scope of the project with the customer (client) i.e., 
creating a context diagram. This diagram identifies the events that "bring the system to life" 
and the response by the system to these triggers. For each event the analysts, idong witli the 
customer, create high-level data flow diagrams (one bubble per event), a mini specification, 
and an entity relationship diagram. Throughout the presentation we discuss the applicability of 
an integrated CASE tool to record and manage all analysis results. We end the presentation 
with a brief discussion of our transition strategy between structured analysis and structured 
design. 

As all good IS shops we were lcx>king lor the "perfect" initial project with which to try our 
wings and concurrently develop an Information Engineering methodology. What was presented 
to us was a project that was just about perfect - almost autonomous (very little interface with 
other systems) and critical enough to present a sense of urgency to get it completed and 
installed. The proposed new system, to accommodate the Graduate and Family Housing office 
of the University, had been in the works for some time. The analyst assigned to the project wa.s 
searching for an alternative to traditional methods to develop this project and presented the 
challenge to our Software Process and Information Engineering group. 

Having done considerable research and self-study into structured techniques, the group 
formed an analysis team and set out to "do analysis." Having been trained in classic DcMarco 
structured analysis we fully intended to do functional decomposition. We discovered very 
quickly that we were not at all comfortable with the main functions we were able to identify. 
Having NOT done an Information Strategy Plan (ISP) for this office led us to groping for 
major functions around which to place our events. Obviously a different approach was needed. 
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A decision was made to involve our customer in facilitated sessions to tap their knowledge and 
hopefully raise our comfort level ax well as shorten the cycle for analysis. Event / Response 
modeling proved to be very useful for this purpose. It is our opinion, having launched the 
second project, that if the system in question contains very little process and large amounts of 
data, BventA<csponse is probably not the best method for analysis. 

When performing structured analysis using the Event/Response technique, you will find 
there are two very definite methodology steps to lie taken. Hie first is to define the scope ol the 
project. With the help of the customer develop the context diagram. From this diagram 
determine the essential events that drive the system. During this process make sure that the 
output as well as the input is analyzed. Often there is output that cannot be directly associated 
with an input "trigger." This output is usually generated by some passage of time (like 
preparing monthly statements), and arc generated by what are called "temporal" events. 
Nevertheless they need to be included in the event list. By looking closely at this kind of event 
it is often simple to combine several similar output reports into a single outflow such as 
"Monthly Reports." With careful definition of the scope of the project, it becomes much easier 
to determine whether a topic brought up lor discussion is really a part of the project or not. 

Once the project scope is firmly established, the second methodology step can be taken. 
That step is to very diligently capture the business policy of the customer in language that they 
can understand. We found the best metluxl fordoing this was to continue the intensive 
meetings with our customer. As a team, and in this part of the process we considered the 
customers as part of the team, we were able to stay on task very well Any item brought to the 
table first had to pass the test of being within the scope of the project. If it was indeed a 
necessary item, it was included in the event list and added to the project. 

In order to capture the business policy effectively, we created our Event/Response models at 
this point in the process. The team discovered a lot of time and effort could be saved by 
following a simple rule of decomposition, Each event defined from the context diagram would 
contain only one bubble. If more than one bubble seemed to be indicated we first looked to see 
if |)crhaps we had more than one event to define. If the team decided there was only one event, 
but more than one bubble seemed to be needed, the consensus was we were trying to 
decompose kx) far for this point in the project life cycle. Being from a programming 
background, the le;un was often not comfortable with the level of abstraction this rule forced 
upon us. but at the end of analysis we were glad we stuck to our guns. 

Another discovery that our analysis team made was the value of outside help. The going got 
much easier when we contracted for consultant help at various stages of this process. The 
consultant we chose was Bill Barbour of Bayswater Associates, We did not contract with him 
to do the work, but to "look over our shoulder" occasionally and advise us on our progress. 
This proved invaluable as a method of shortening the learning curve. While the cost of 
consultant help may look very expensive on the surface, it is worth it's weight in gold to the 
development of a methodology that will work in your environment. 

As the models arc developed, it is very helpful to have access to a fully integrated CASE 
tool to capture your analysis as you go. We use the Knowledge Ware set of tools, but any fully 
integrated CASE tool will serve your purposes very nicely. After the data flow diagrams were 
developed, precise definitions of each and every data flow were developed. This definition 
helped to nonnalizc and stabilize the data model. The CASE tool was fully utilized at this point 



to capture definitions for data items as well as allowable values (if known) for further use by 
the design team. Liberal use of comments were made. Careful attention to just what data are 
present and which data are actually required can help shed light on future uses of data. One of 
the benefits of these intense customer sessions was to facilitate Business Process Redefinition 
as we went through the process. Having discussions about possible future uses for data helped 
in the modeling process. In addition this information will be valuable at the design stage as a 
guide to development of the current system as well as keeping an eye on the future. 

With the completion of the data How diagram mid data flow definition for each event, the 
mini-specs arc then developed. Careful attention must be given in this step to dealing with 
"what" the system is trying to accomplish, not "how" it is to be done. This is very difficult to 
do and takes a lot of practice. If i<x) much attention is paid to the form (structured English) and 
not enough to content (what we we defining ?) the result will look very much like pseudocode. 
The mini-spec, is a good place to store things such as formulas, rates, or design notes. While 
these items are definitely part of the "how", the emphasis in the thought process musl stay 
tuned to the "what" of the system. As a general rule of thumb our team discovered that any 
mini-spec, much over a page mid a half would contain too much "how". 

Just a mention here about time constraints. We've all been through the scenario on system 
development projects where analysis was done because it was a checklist item on the project 
plan. If analysis was slated for two months and two months arc up then "analysis is done - let's 
get on with design". In order to cut the cycle and help make cultural change happen, the team 
must he conscious of time. Time boxes need to be established, probably one for each event, 
and consensus reached within that time. If some item is holding up progress, leave it and push 
on. This entire process is iterative. When you have something done (notice we didn't say 
perfect) it should be shared. This "first cut" approach works well to keep things moving. Try to 
gain consensus within three iterations. If this is not happening, chances arc you are delving into 
too much detail. Learning to think at this level of abstraction is not easy. It takes a lot of faith 
that the process will work. For us it worked well. 

Along with the mini-specs and data flow diagrams Information Engineering also requires a 
fully attributed :md normalized data model. You may find developing these diagrams a work 
effort done without the customer. Of all the "new" requirements definitions our team worked 
on, the customer found it hardest to understand an entity relationship diagram. A fully 
attributed and normalized data model, however, is the cornerstone of the design step in the 
Information Engineering discipline. Careful attention to producing this work product will pay 
big dividends down the road. Your CASE tool is a big help here if it is fully integrated. It is 
much easier to create an "entity view" for each event, than to try and keep up with the entire 
entity model for the project. An Integrated CASE tool will automatically create the overall 
entity model from each event's entity view. The CASE tool's relational translator will take the 
entity model and produce a "first cut" data base schema. Please notice this is done from the 
data model, not the mini-specs or any part of the process model. 

When the above steps arc complete for each event and consensus has been reached, it's lime 
to pause for a moment and reflect on the process you just went through. If the customer has 
been with you every step of the way then you will have joint ownership of the system from this 
point on. The customer can say, with sonic pride, that the system about to be developed is their 
system. This will help solve customer involvement issues further on in the process, most 
notably at prototyping and test time. 
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What are the advantages of Event/Response modeling ? The diagrams and techniques used 
appear to be more intuitive to the customer. They don't have the feeling that the process is as 
mysterious as they perceived it to be. Working with pictures as well as words made the 
process go much faster. With our initial project traditional analysis would have been estimated 
to take between six and nine months to complete. Information Engineering estimation said it 
should take four months. While it took longer than four calendar months, we were quite happy 
with the result. We measured how much time we spent in methodology development (in hours) 
based on working through the analysis versus total hours spent on the project. By taking away 
the methodology hours we discovered the estimate of four months was very close, even though 
this was an initial project. 

Another advantage of the process is the ability to do Business Process Redefinition as we 
went along. This introduced good ideas up front while they were still fresh in everyone's mind. 
Any idea was explored for feasibility. If it was able to be accommodated easily, we added it to 
the analysis. If we did not choose to include it, at the very least it was documented for future 
enhancement. By enforcing the rigor of Information Engineering , the models we create are 
ready if we decide at some time in the future to transition to Object Oriented design and 
construction. 

We used the Knowledge Ware CASE tool set to do several things. We used the Data Flow 
Diagrammer module to represent Event/Response models. We used the Entity Relationship 
Diagrammer module to represent object partitioning. The Minispec Action Diagrammer was 
used to represent process models. In addition our team used the DOC Workstation to create a 
comprehensive analysis document for use by the design team. Included were all of the 
diagrams, the data definitions, the mini specs and other information from text files deemed 
useful for the design step. 

The final subject to he addressed in this presentation will be the transition from analysis to 
design. There are many schools of thought on how to manage this phase. Since agreement 
could not be reached, we created our own method in consort with our consultant. The 
deliverables from this process are as follows: 

1. Create Entity/Process (CRUD) Matnx 

2. Walk-through with Design Team 

3. Create first-cut data base schema with Relational Translator 

4. Create activity list from mini specs and identify processors 

5. Create transitional Data Flow Diagram from activities 

6. Identify Central Transform 

7. Create first-cut Structure Charts 

Creation of the CRUD matrix as a last step in the analysis process will verify the essential 
activities. We were able to make sure that each entity was created, updated, deleted and read 
by at least one activity (event). If you notice an activity which only reads lots of data without 
producing anything (not even a report), it is a good bet that it is not a necessary activity. 

Walking through the analysis document with the design team is a very good verification 
tool. By addressing the questions and comments of the designers any lingering "holes" in the 
analysis should be uncovered. When the design team begins to prototype for screen formats 



and report layouts, they may uncover some subtle changes that need to be made to the analysis 
model But as a rule the major oversights will be uncovered during the walk-through process. 

The next step is to use the CASE tool to process the entity model through a relational 
translator and create a first-cut data base schema. These tools are very goal at highlighting 
missing candidate keys to help the team create unique instances of each entity and/or 
relationship. Doing this process manually would take enormous amounts of time and would 
always be suspect of having "missed something". 

Creating a list of activities from each mini-spec begias the process of design decomposition. 
In this process the processors are identified also. Here is where the first determinations are 
made, activity by activity, whether the processor of the activity will be a person or the system - 
- or the drawing of the classic "man machine boundary". No attempt is made here to sequence 
events — just create the list. This process will begin to identify things such as input 
verification (edits), volume and frequency counts, and perhaps some process redefinition for 
the manual processes which take place in support of the computer system. It is important to 
remember that this in no way implies changing manual methods to accommodate a proposed 
computer system, but rather a smooth incorporation of both machine and manual processes. 

Once the activity list is created from the mini-spec the team can create a transitional data 
flow diagram from it. Previously we addressed the problem of taking decomposition to a level 
too rich in detail. Here is the place for such decomposition. At this point the team is very much 
aware, as is the customer, of many subtle conditions and business policies which led to the 
creation of the activity list. At this point it now makes sense to decompose our event bubble to 
picture the activities in a data flow diagram.. Experience has taught us that enormous amounts 
of time and energy can be saved by postponing decomposition until this point. Our models will 
typically contain only three or four levels of decomposition even after we have done this 
transitional data flow diagram. Looking over our experience we feel safe in saying that making 
the mental shift from infinite detail (traditional) to the abstract (structured) was die most 
difficult task in the entire process. We were used to thinking analytically at a level of detail that 
properly belongs on the structure chart in the design process. 

As the transitional data flow diagram is produced, be giving some thought as to which 
activity is the central transform activity. This activity will be the prime candidate for the 
control module in the structure chart for the process under study. 

Finally the first-cut structure chart will be created. We call it first-cut for a reason. Like the 
analysis, this will be the first working document in the design process. It is intended to be a 
starting point for proper definition of code modules to be identified in the design process. As 
prototyping begins and implementation issues begin to be dealt with the structure chart will be 
refined to the point where coding assignments may be made at the transition from design to 
construction. 

Having emphasized the role of the team throughout this presentation, let us take the 
opportunity to make the point one more time. The entire process of Event/Response Modeling 
cannot take place in a vacuum. The dedication and involvement of all team members is critical. 
Working together brings out a synergy that facilitates the process both in duration and, more 
importantly, the quality of the product produced. As you proceed in your transition from the 
traditional systems development methodology to Infonnation Engineering you will face many 



and varied trials and tribulations. The cultural change that is required by itself is large, 
good news is that as you reach each milestone along the way you will feel a sense of 
accomplishment - a sense that the entire process is worthwhile. 
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Horror Followed by Heroics: 
Recovery from Hurricane Andrew 



Albert L. LcDuc Debbie Stcdman M. Lewis Tcmarcs 

Director, Computer Services Systems Analyst V.P. & CIO, Information Systems 

Miami-Dade Community College Miami-Dade Community College University of Miami 



Not only did Hurricane Andrew provide us with some valuable disaster recovery 
lessons, but the experience provided all of the citizens of South Florida with some 
emotional lessons as well. This paper outlines some of the lessons and experiences 
from the perspectives of both Miami-Dade Community College and the University 
of Miami. 

"No single thing could have done more to restore the confidence of the 
people than the fact they got their paychecks on time. " 

Dr. Carl Eisdorfer 

Chairman, Department of Psychiatry 

University of Miami 

The University of Miami Perspective 

Hurricane Andrew arrived on August 24 with winds up to 175 mph. At the 
University of Miami, for example, 35 roofs, 800 windows and 3000 trees were 
damaged, broken or destroyed. Over 400 employees lost their homes and over 5000 
reported claims in excess of $5,000. Almost 5000 parents and students were on 
campus for orientation day and the opening of the residential colleges for the Fall 
semester. They rode out the storm huddled on the floors in hallways. 

Immediately after Andrew calmed down, the recovery began. The University of 
Miami's Public Safety Director went to the President's house and, "crashing through 
the woods," brought him to campus. The people in the telecommunications building 
computing center, residential colleges and other shelters on campus, like groundhogs, 
slowly came out and saw the campus in shadow. Roads were impassable and with 
little power or phone service in the county, food and supplies were threatened. The 
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health of the people on campus would become a growing concern as facilities became 
overburdened. 

Communications on campus never faltered except the buttons on the phones did not 
light nor did the ringers ring. Mobile phones were clogged, regular service was 
spotty, and blue jeans and sneakers were joined by beepers as the dress code. 

Because there are additional concerns for the employees of the institution as well as 
the student population at a residential college/university, both institutions learned 
first hand about the human side of disaster and recovery planning and 
implementation. As an example listed below are some of the things the University 
of Miami did: 

1. Daily meetings were held by the President with administration, faculty, and 
staff to exchange information and make decisions. 

2. A census of the University employees was begun. Within a week, all but 400 
were accounted for. After search parties were sent out, everyone was 
accounted for. 

3. School was delayed for 18 days. 

4. Students were offered the opportunity to go back home and be reimbursed 
with credit to their Spring tuition. 

5. Employees were told to stay off campus until August 31, to allow time for 
clean-up and repair. (350 stayed) 

6. A volunteer clearing house was established and 300 students worked side by 
side with University employees. 

7. A program named UM Cares About Neighbors (UM-CAN) was begun to get 
relief to UM employees. Foodstuffs and money were collected to help less 
fortunate employees. 

8. The student health center was opened 24 hours a day with a doctor and a 
nurse always available. 

9. Facilities Management began cleaning up the campus. Contractors from Palm 
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Beach, commercial grinders from Georgia, and tree-trimmers with chain saws 
from 4 states worked from dawn to dusk. 

10. Water trucks and 35 portable toilets were placed in the residential complex. 

11. Physical Plant crews went out with plywood, roofing materials and generators 
to secure the homes of University employees all over the county. 

12. Over 200 Florida Power & Light employees from out-of-county were housed 
at the recreation center while they worked to restore electricity in South 
Dade. 

13. While telephones never went down at the campus, a communications link to 
the Virginia Key campus was destroyed. Part of the backbone on campus was 
broken by an uplifted tree whose roots had grown under the cable. 

14. The computer system, totally backed-up, could not come on-line because it 
was water-cooled and the water pressure on the campus was too low. After 
intense efforts for two days, the system was up and running normally. Payroll, 
including direct deposit, was available on time. 

15. Housing for faculty and staff who lost their houses was arranged by the 
individual and the University. Apartments 20 miles from campus were leased 
by the University for those in need. 

16. The Purchasing Office was available so the University could buy everything 
it needed - from water to portable toilets to rebuilding supplies to hotel 
space. 

17. Police officers worked 12 hour shifts to secure the campus. They were 
supplemented with officers from other universities. 

As a whole, the University suffered up to $15 million damage, of which half is 
covered by insurance. FEMA has been asked to cover most of the remaining 
portion. The University is looking at a $1 - 4 million problem during the 1992-93 
academic year, not including lost revenue. But, although a tremendous hardship, 
recovery will occur. "1 was so proud of our associates," said President Foote. They 
just did a super job under the most difficult of conditions and with real bravery. 
Hemingway said 'courage is grace under pressure* and it's difficult to imagine more 
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pressure than this place was under. There couldn't be more courage in so many 
wonderful people than I saw displayed at this University." 

Insights from Miami-Dade Community College 




Andrew, the greatest natural disaster in US history, provides an interesting case study 
for disaster planning and recovery. Although it is difficult to interpolate this 
experience, at Miami-Dade Community College several conclusions were reached. 

1. A Disaster Plan is imperative, if only to provide a set of rules to go by so that 
preparation for an impending disaster can take place in an orderly fashion. 

2. Information Technology areas are far better prepared to deal with preparation 
and aftermath than the rest of the organization. There can be some 
misunderstandings and tension as a result. 

3. Most organizations do not understand the nature of their vulnerability to 
technology disruption, especially if high standards of service are the norm. 

4. Rehearsal and practice, as well as follow-up, need to be a matter of rigor and 



5. Communications during and after the disaster can be a very distinct problem. 

With the planned support of Dade County Public Schools, the M-DCC payrolls were 
processed on August 27, 3 days after the storm. Due to tenacious people who used 
creative ways of navigating through the devastated areas, the checks were distributed 
to College employees on time. With additional support from vendors, the computer 
systems were brought back up on September 3. On September 8, the College opened 
for business as usual, and on September 14, classes started for the Fall Term, two 
weeks later than scheduled. 

As someone has said, Andrew was in a different category than most disasters that 
occupy the media. For people directly affected, it was more like a warfare disaster 
than a storm. The disaster area encompassed 300 square miles of area, caused as 
much as $30 billion of damage, and placed 450,000 residents in home and business 
crisis. Two campuses of Miami-Dade Community College were seriously affected. 
The Homestead Campus had portable classrooms destroyed; the Kendall Campus 
had one building (which was used as an evacuation shelter) seriously damaged. That 
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campus was used as a shelter site, a food and water distribution site, and a bivouac 
site for Army and National Guard troops. 

Is it any wonder that under these awesome conditions, the psychological effects of 
a disaster of this magnitude lasts for months? It should be noted that when planning 
for a disaster, people's emotional states should be taken into account. Every member 
of the disaster recovery team will very possibly be a victim of that disaster. The 
trauma of a disaster like Hurricane Andrew throws people so far out of their range 
of equilibrium that it is difficult for them to restore a sense of balance in life. The 
trauma is caused by all of the loss experienced by the victims. 

. Loss of control over one's life 

, Loss of faith in one's God or other people 

. Loss of loved ones or personally-significant property 

, Loss of a sense of immortality and invulnerability 

. Loss of future 

This tremendous sense of loss experienced by the victims in the disaster area causes 
people to experience a range of emotional reactions: 

Stage I: Shock, disbelief, denial 

Stage 2: Anger, fear, grief, frustration, guilt 

Stage 3: Acceptance, reconstruction of equilibrium 

Because these emotional reactions are experienced by the majority of people living 
in the affected area, work productivity has been affected. Additionally, the stress 
reactions which manifest themselves in the victims should most probably be dealt 
with specifically and professionally. At Miami-Dade, for example, support groups 
facilitated by mental health professionals were held for several weeks after work 
resumed. Mental health information, including what type of emotional reactions 
were occurring and what help was available, were distributed widely and often. 

CONCLUSION 

Information technology organizations often deal with crises. Hurricane Andrew 
pushed those organizations to the forefront of the preparation and response needed 
at both the University of Miami and at Miami-Dade Community College. 
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Professionalism, a sense of duty, unusual tenacity, and responsibility, especially as 
exhibited by Information Technology personnel, helped these institutions recover 
from this unique and critical disaster. 
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Business Reengineering in Higher Education: 
Promise and Reality 

James H. Porter 

Associate Director, Administrative Information Systems 
The University of Chicago 

Telephone: 312/702-4501 
Internet: j-porter@uchicago.edu 



Over the past few years business managers have been told to obliterate, reengineer, 
transform, break 1 and do all sorts of things to their organizations. Should we be doing the same 
things within higher education? This paper takes the position that business reengineering has not 
yet been applied within higher education institutions and, for the foreseeable future, will not be 
applied to a major university. In addition, process redesign, a specific step in the business 
reengineering process, should not be applied in most of our institutions of higher education. 

Reengineering in Business vs. Reengineering in Higher Education 

Business reengin *,ering can be defined as: 

...the fundamental rethinking and radical redesign of an entire "business 
system" — the business processes, jobs, organization structures, management 
systems, and values and beliefs— to achieve dramatic improvements in critical 
measures of performance. 2 

While the process described in this definition may apply to business organizations such as, 
say, manufactures of electric toasters or cold cereal, business reengineering' s application to higher 
education is not clear. If we are to reengineer our universities, what jobs, organization structures 
and management systems do we radically change? What are the critical performance measures that 
will dramatically improve? To answer these questions, it may help us to compare a 'business 
system' to a similar model of a 'higher education system.' One widely accepted business system 
model is Michael Porter's Value Chain, 3 as shown in Figure 1. One interpretation of Porter's 
Value Chain is that the Primary Activities listed across the bottom, taken together, comprise the 
Business Processes of an organization. 
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Figure 1 . Michael Porter's Value Chain 
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A comparable model of a university might replace the Primary Activities in the bottom half 
of the Value Chain with Education and Research — which represent the Core Mission of higher 
education institutions. In other words, education and research are the business processes in higher 
education. In addition, General, Student and Research Administration and Enabling Technology 
would replace the Support Activities in Porter's Value Chain. This proposed model is presented in 
Figure 2. (A colleague, who will remain nameless, suggested that Education business process be 
divided into three primary activities: recruiting, awarding degrees and soliciting donations.) 
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Figure 2. A Proposed Higher Education Value Chain 

We can represent the business processes and support activities indicated in the Proposed 
Higher Education Value Chain in a possibly more meaningful format by organizing them into three 
tiers as suggested in Figure 3, A Business Model of a University. 




Figure 3. A Business Model of a University 
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If we accept this three-tier model as a valid representation of a university, then applying 
business reengincering implies a top-down transformation of all three tiers. To reengineer the 
university — or any other organization — we ask "What business are we in and what business 
should we be in? Who are our customers? What products do they need? How should we be 
organized? What technology do we need to support our radically changed mission?" To answer 
these questions, we first would rethink the university's mission, including its core business, 
customers and markets. We would then examine the environment, competitors and market 
conditions. We then, according to business reengincering theory, might develop a vision of the 
university as a different organization. Maybe we should do away with the students and become a 
research-only institution. Maybe wc should throw out the students, researchers and administrators 
and go into real estate development. Or maybe we should. . .. 

Sure! Propose taking such actions to the trustees, faculty and alumni of any major research 
institution and you will be fired, committed, or worse; however, some institutions — notably certain 
small private and community colleges — have taken reengincering-like actions, due to competitive 
or survival threatening situations. (Several such examples are presented later in this paper.) An 
analysis of these few data points suggests that there may be a correlation between size and type of 
an institution and its propensity to reengineer. One possible model is represented by the continuum 
proposed in Figure 4. 
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Figure 4, Propensity to Reengineer in Higher Education 



As university administrators, what does this model mean to us? It suggests that if we are on 
the staff of a major research university or public institution that is not in serious trouble, we are 
probably wasting our time to propose business reengincering. The model also suggests that if we 
are in a small, private institution or community college and we are under severe financial or 
marketing pressures, reengincering may be our key to survival. 

Business Transformation 

In theory, you do not have to make fundamental changes to the institution in order to take 
advantage of reengineering concepts. Reengineering is, according to some, the culminating phase 
of a multi-phase process. One such multi-phase process, presented in Figure 5, comes from the 
Management in the 1990s Research Program at MIT's Sloan School of Management. 4 We will 
refer to this model as the MIT 1990s Transformation Model. 
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Figure 5. Five Levels of Information Technology-Induced Transformation 
(MIT 1990s Transformation Model) 



The five phases suggested in the MIT 1990s Transformation Model, which takes an information 
technology perspective, can be described as follows: 

Levels 1 and 2 are evolutionary and will result in incremental changes to existing processes. 

Level 1 Localized Exploitation — The use of computers to improve the 
efficiency of one business function. Examples include the 
deployment of stand-alone student systems, financial systems and 
human resource systems, which are frequently from different 
vendors, written in different languages, using different databases 
and sometimes operating on different hardware platforms. 
Departmental shadow systems — which locally duplicate data from 
other systems — are another example of localized exploitation 
systems. While users across an institution may use these systems 
for transaction input and inquiry, local efficiencies and local control 
are the real goal of local exploitation systems. This is the current 
status in many, if not most of our institutions. 

Level 2 Internal Integration — The interconnection of business activities 
through a common technological base and shared organizational 
vision. Level 2 organizations experience efficiency and effectiveness 
through cost reductions, the creation of value-added services and 
improved information availability for decision making. 
Organizational responsibilities are typically adjusted to take 
advantage of new capabilities. Few of our institutions are at this 
level. 

Most projects currently reported in the university trade press under the rubric 
"reengineering" and "process redesign" fall into the Level 1 or Level 2 categories. 
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Levels 3, 4 and 5 in the MIT 1990s Transformation Model are revolutionary and will result 
in fundamental changes to existing business processes and supporting organizations, with 
both potential benefits and degree of resulting business transformation increasing as we 
move to higher levels. 

Level 3 Business Process Redesign — Business processes are 
redesigned to take advantage of the enabling powers of information 
technology — which will result in redesigned organizational roles, 
reporting relationships and managerial responsibilities. Even if we 
limit applying this level to only the Enabling Technology and the 
Administrative Processes tiers as described in Figure 3, this level 
will be difficult to achieve by a major university because (1) the need 
to redesign our administrative processes has not been demonstrated, 
(2) the benefit from redesigning our administrative processes is not 
known, and (3) the organizational and management support required 
to redesign our administrative processes will be difficult to gain. 
(Remember, according to this model, most of us are at Level 1 and 
most of the systems and organizational projects we are currently 
implementing would be placed in Level 1 or Level 2 categories.) 

Level 4 Business Network Redesign — This is inter-organizational 
integration through inter-company networks, electronic data 
interchange, etc. Examples include linking multiple companies' 
manufacturing and inventory records so that, say, a seat 
manufacturer knows the production schedule of a car manufacturer 
and can get the right color and style of seat to the production line 
just-in-time. There is no equivalent requirement for network 
redesign, as defined, in higher education. 

Levels Business Scope Redesign — The redefinition of an 
organization's mission through the capabilities of information 
technology. When reengineering is applied in the corporate world, it 
may lead an organization to getting out of its old business or adding 
new businesses, such as selling information as a product or offering 
other value added services. In higher education, if we get out of the 
education and research business, we are no longer in higher 
education. 

The MIT 1990s Transformation Model presents a dilemma in that the definition of business 
reengineering presented at beginning of this paper would fall somewhere between Level 3 and 
Level 5 in the Transformation Model (Level 4 should be ignored). Likewise, the definition of 
process redesign we are using falls somewhere between Level 2 and Level 3. One point the reader 
should note is that there are different levels of business transformation — and that process redesign 
and business reengineering are not the same activities. Process redesign is required to achieve 
business reengineering; however, business reengineering is not required to apply process redesign 
to an organization. 
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Change Options 

Given the above discussion which states that most organizations are probably at the Local 
Exploitation level in the MIT 1990s Transformation Model, how can we proceed to change our 
organizations? Several possible approaches are presented in Figure 6, Business Systems 
Change Options. 



Approach 


Action 


Management Support 
Required 


Feasibility 


Static 


Do not make any changes. 


No special management 
support required. (May need 
management s proiccuonj 


Not likely. Always some 
change. 


New System 
Project(s) 
(Localized 
Exploitation) 


Implement new 
administrative applications 
and/or hardware. 


Local sponsor support required 
throughout project. Little 
senior management support 
required 


Doable; but new systems 
alone do not constitute 
redesign or rcengineering. 


Incremental 
Change via 
Internal 
Integration 


Move application systems 
to common 

architecture/technology. 


Little senior management 
involvement required. 
Need common vision and 
good plans. 


Many universities 
working toward Internal 
Integration. 


Administrative 

Process 

Redesign 


Significant change to 
administrative processes 
incorporating the enabling 
capabilities of information 
technology 


Senior management support 
required to initiate. Ongoing 
support required. Changes to 
organization will be resisted. 


Feasible. Possibly not 
desirable. Benefits not 
demonstrated. 


Business 
Rcengineering 


A transformation of the core 
business. Fundamental 
change to the mission, 
markets and products. 
(Education and research) 


Broad, senior management and 
community support required 
throughout rcengineering 
effort. 


Possible for institutions 
in a serious financial or 
competitive trouble. Not 
likely for major research 
institutions. 



Figure 6. Business Systems Change Options 



Using the three-tier model proposed in Figure 2, the MIT 1990s Transformation Model, and the 
change options outlined in Figure 6, our alternatives include: 

• Change the middle tier: Change the enabling technology by, say, installing a new 
computer application. This can be accomplished without disturbing the other two tiers. 
Indeed, many organizations insist that new administrative application systems must not 
change current administrative processes. This is a Level 1 approach. 

• Change the bottom two tiers: 

- Level 1 change — Install a computer system or make organizational changes to 
gain efficiency in one area or department. Shadow systems developed by, say, a 
unit, division or department are Level 1 projects, as are financial, human resources 
and student systems that are not integrated with other administrative systems 
through a common architecture and database. 
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- Level 2 change — Integrate the current administrative processes using a common 
technological base and shared organizational vision. This will usually result in 
technology-driven change and will redefine some administrative organizational 
responsibilities. This is the path most universities should take — and are taking — no 
matter whether they call their effort a reengineering, transformation, redesign, or 
whatever project. 

- Administrative process redesign — Redesign the administrative processes. If 
the administrative processes can be redesigned, the result will be changes in the 
technology and process tiers — but no major impact on the top tier. True 
administrative process redesign will be difficult to achieve in a university due to 
lack of support, opposition by vested interests, and limited demonstrated realizable 
benefits. Most universities should use the evolutionary, Level 2 approach. 

• Change all three tiers: Reengineer the core business processes — education and 
research — and all supporting organizations including redesigning the administrative 
processes. Requires Board of Trustees and faculty support that will be impossible to 
achieve in most universities. 

Level 2 of the MIT 1990s Transformation Model, Internal Integration, is the transformation 
activity applicable to most of our institutions. It allows us to take advantage of the enabling powers 
of information technology without significantly threatening the mission-related activities of the top 
tier that might result from reengineering or invoking the resistance resulting from organizational 
changes that would result from administrative process redesign. 

Reengineering Experiences in Higher Education 

There are no examples in the literature of business reengineering, as defined in this paper, 
being applied within higher education. I can find no documentation of a university that has gone 
through a classic business reengineering process. 5 Some institutions have reportedly discussed 
reengineering and others have taken reengineering-type actions due to financial or other pressures. 
Business reengineering-like examples reported in the press include: 

• Small colleges, especially private institutions, are merging with larger colleges. 
For example, Mundelein College and Mallinckrodt College merged with 
Loyola University. Between 1988 and 1992 over 30 mergers were completed. 6 

• Tougaloo College, under the leadership of its President, pulled together 
faculty, alumni and administrators to establish a stiVegic plan to address 
serious financial problems. One action Tougaloo took was to lease college 
owned property to businesses wishing to expand. 7 

From 1985 to 1990, St. Mary of the Plains College operated a vocational 
training program in conjunction with a truck-driving school. High student loan 
default rates by students in the vocational program are a major reason the 
college closed in June 1992. 8 

• Columbia University's Martin Meisel, member of a strategic planning 
committee consisting of administrators, faculty and students, was quoted by 
the New York Times as stating that "What might emerge [from the planning 
process] is likely to be a different institution." However, Columbia's 
President, Michael Sovern, is quoted in the same article as saying "I don't 
think that the changes are likely to be the sort that anyone outside the institution 
will see." 9 {It will be interesting to see how these differences are resolved. } 

; 

i 
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Numerous community colleges have added traditional and non-traditional 
programs to meet specific local needs. 



Possible administrative process redesign examples are easier to find. CAUSE, for instance, 
recently surveyed its membership with the following question: 

Has your IT organization engaged in any reengineering projects on campus, 
i.e., looked at ways to make administrative processes more effective and 
efficient and to incorporate information technology into these operations? 10 

The question, as phrased, reflects the existing confusion over the differences between 
business reengineering and process redesign that this article is attempting to address. The five 
projects highlighted in CAUSE/EFFECT would be classified as Level 1 or Level 2 projects using 
the MIT 1990s Transformation Model. Four of the reported administrative process redesign efforts 
are summarized in Figure 7. 



University 


Process Being 
Redesigned 


Methodology Followed 


Remarks 


Virginia 
Tech 


Human Resources and 
Financial Aid 


Consulting Model. 
Traditional business analysis, 
design and development. 


New department 
established to address 
administrative systems 
and related 

opportunities.(Level 1) 


Yale 

University 


Human Resources and 
Payroll 


Applying Expert Technology 


Paper forms reduced 
by over 50% 
(Level 1) 


University of 
Pennsylvania 


University's Financial 
Management Process 


Three-pronged process: 

(1) Develop an information 
architecture 

(2) Identify Business 
Requirements 

3) Acquire integrated 
administrative 
applications over time 


Sponsored by Vice 
Provost for IS and 
Vice President for 
Finance (Level 2) 


University of 
Michigan 


Graduate Student Aid 
Process 


Joint Application Definition 
(J AD) and TQM 


(Level 1) 



Figure 7. Selected Administrative Technology Projects From CAUSE/EFFECT 



Another administrative process redesign example is a major system implementation project 
at Columbia University. This activity was reported in the November 9, 1992 Computervjorld 
under the title Assignment: Re-engineering". 11 While the author used the term "re-engineering" to 
describe the ambitious undertaking at Columbia, what is described in the article is an administrative 
process redesign project which would be classified as a Level 2 project in the MIT 1990s 
Transformation Model. 
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Reengineering in the Business Press: Title Inflation 

One problem we have in separating business reengineering efforts from traditional system 
projects is caused by the business press. Take, for example, the following scenario based upon 
imaging: 

Imaging i , a technology that will receive much press coverage over the next few 
years. Most imaging applications are put in place to: (1) route electronic copies of 
forms for review, action or approval, (2) track the status of these forms, and (3) 
provide electronic filing and retrieval of these forms. 

The forms used in an imaging application are about the same as the pre-imaging 
forms. The people reviewing the forms are the same people who reviewed the paper 
forms. The same decisions are being made. If the unit using imaging were placed in 
a black box, the outside world would notice little difference. The only indication 
that imaging was being used would be faster decisions coming out of the box and 
more money being sucked into the box. 

This is an example of a Level 1, Local Exploitation application of technology if 
there ever was one; however, you can be sure that any article covering imaging will 
declare the project to be a reengineering project. 

Conclusions and Recommendations 

In my investigation of reengineering in higher education, I felt kinship with a 
cryptozoologist looking for sasquatch or the Loc Ness monster. A cryptozoologist, in searching 
for these possibly mythical beasts, considers "...reports by eyewitnesses or indigenous peoples; 
descriptions in folk stories, travelers' accounts, old manuscripts and legends...." 12 As a 
cryptoreengineerist, I have talked with indigenous university computing peoples, listened to folk 
stories (presentations at conferences) and legends (from vendors) and reviewed old manuscripts 
(articles in the trade press) and have yet to find business reengineering in higher education. Maybe 
someday, someone will capture a real live higher education business reengineering specimen. 

Is there anything wrong with using the terms reengineering and redesign if we are actually 
engaging in Level 1 and Level 2 projects? If it helps you to sell the project to management or if you 
feel better about having a project with reengineering or redesign in its title, by all means, use the 
terms; however, if you really believe that you are going to significantly change your university's 
business or its administrative processes or you are setting management's and user's expeciations 
for important and major changes, you are in for serious problems. 

As the administrative and technology professionals in our respective institutions, we must 
be careful to understand what is implied as we consider applying concepts from the corporate 
world to higher education. Sometimes we lose our perspective and assume that the administrative 
processes we support are the university. 

Business reengineering has had a major impact in the corporate world but will not be 
applied within our universities — oxcept in an institution in serious trouble. Administrative process 
redesign should not be attempted since there is no demonstrated need, no documented benefit and 
no organizational support for such an effort. Rather than attempting business reengineering or 
process redesign, we should focus on achieving Level 2, Internal Integration as described in the 
MIT 1990s Transformation Model. Let us use information technology to help the administrative 
organizations we have in place achieve their potential before we attempt major changes through 
redesign or reengineering. 
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Introduction 

There is an old saying that the only things we can count on are death and taxes. In higher 
education, it is also a good bet that change will be a key word for the remainder of the 
twentieth century. Finances, faculty issues, deferred maintenance problems, diversity, student 
financial aid, political correctness, global issues, and tuition are only a few of the issues that 
will be considered during the 1990s. Within this framework of uncertainty, the senior 
computing person has to operate proactively and reactively to the changing needs of her/his 
constituency. With that in mind, many surveys of the key issues confronting the information 
technology leader are undertaken. The main purpose of these surveys is to provide direction 
and insight for IT managers. Most surveys of this type are taken by business and industry and 
while the comparisons with issues in higher education are important, it is significant to look 
at the issues directly facing higher education and how relevant they are perceived to be by 
the people who are senior tofficers with IT responsibility. 

The issues that were included in this CAUSE postcard survey were derived from the authors' 
experiences, from reviews of current literature dealing with IT issues facing industry and 
higher education, and from a review of the responses to a similar survey taken in 1991/92. (A 
CAUSE postcard survey is designed to be short and fit on one side of a postcard.) The survey 
was also designed to allow participants to list and rank other issues which were deemed to be 
important IT issues for their campus in the 1990s. Several new issues were included in the 
1992/93 survey based on the numbers of people who included them in the other issues 
category from 1991/92, client/server, downsizing, and quality issues. Data from the CAUSE 
Institution Database (ID) were downloaded and merged with the postcard data. This allowed 
the researchers to analyze the data based on various institutional characteristics, including 
size, control (public or private), and Carnegie classification. (For the purposes of this study, 
institutions have been grouped by the categories used in the classification of US. institutions 
of higher learning by the Carnegie Foundation for the Advancement of Teaching. Categories 
Comprehensive I and II were combined under the heading "Comprehensive," Doctoral 
Granting I and II under "Doctoral," Liberal Arts I and II under "Liberal Arts," and Research I 
and II under "Research.") 

Survey Instrument 

One of the many CAUSE member services is the Postcard Survey Service. Members can 
conduct informal surveys of other CAUSE members to collect information through a survey 
postcard sent to all member campuses. Members return these pre-addressed postcards either 
to the member requesting the information or to the CAUSE national office. While this survey 
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was instituted by Dr. M. Lewis Temares, Vice President and CIO at the University of Miami, 
the survey was mailed back to the CAUSE national office and data entry was handled by Ben 
Zastrocky, CAUSE Research Assistant for Information Resources. Data analysis was 
performed by Dr. Temares and Dr. Michael Zastrocky, CAUSE Vice President. This survey 
was mailed to 1038 institutions of higher learning in the US. and to all CAUSE international 
member campuses. The response rate was 52.8 % with 548 completed postcards received. 
This compares favorably to the 1991/92 survey where 888 surveys were mailed and 503 
returned for a 56.6% response rate. The following questions were included on the postcard 
survey: 



CAUSE Postcard Survey: IT 
Issues in the 1990s 

Rank the following information technology 
issues in order of importance to you in the 1990s. 
(1 = greatest importance. Use the "other" line if an 
issue you consider important isn't listed.) 

Security Issues 

Reengineerin g 

Networking 

Staff Development and training 

Aging Systems 

Effectively coping with limited resources 

Developing an IS strategic plan 

Quality issues 

Justifying the value of IS 

Downsizing 

Client/Server 

Other: 



Institution name: 
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Summary of Results 

Networking and effectively coping with limited resources are identified as the most .critical 
issues facing higher education during the 1990s as reported in this years survey of CAUSb 
institutions This follows very closely the results from the previous years survey What is 
interesting is that the ranking of these two issues was generally the same for both surveys 
regardless of size, Carnegie classification, or control (public versus private). The one exception 
from this years survey was by size. Institutions with an FTE greater than 18,000 Mb rated 
"Coping With Limited Resources" (49% ranked it in their top three) higher than Networking 
issues (43%) for 1992/93 . 

Several new issues were added to the survey for 1992/93, Client/Server, Downsizing, and 
Quality Issues. Of the new issues Client/Server was ranked most important of this group. 
Overall, 30% ranked Client/Server issues in the top three while only 15% ranked Quality in the 
top three, and 14% ranked Downsizing in the top three. 

While "Justifying the value of IS" was at the bottom of the ranking of the top three for 1992/93 
at 14%, this was up from 10% who ranked it in the top three on the 1991/92 survey. 

It is interesting to note that the greatest spread between the ranking of the top three by 
Carnegie Classification was with the issue of Reengineering. 33% of the Research universities 
ranked it in their top three, while only 7% of the 2-Yr.. colleges ranked Reengineering in their 
top three. Another interesting spread was with the issue of Networking 71% of the smallest 
institutions (FTE<2,000) ranked this issue in their top three while only 43% of the largest 
institutions (>1 8,000 FTE) ranked Networking issues in their top three list. 

The differences between public and private institutions were small. The greatest difference 
came with the issue of "Coping with limited resources" which was ranked in the top three by 
53% of the private institutions and 58% of the public institutions. 

Differences between the categories that were listed at the bottom were quite different. For 
example, 50% of the 2-Yr. colleges ranked "Coping With Limited Resources in the bottom 
four while only 1% of the Liberal Arts colleges, 5% of the Comprehensive, 4% ot the 
Doctoral Granting, and 7% of the Research Universities placed it in the bottom four. 

The first set of charts indicate the ranking of all responses in the top three category based on 
size control, and Carnegie classification. The second set indicates the ranking of all responses 
in the bottom four categories based on the same characteristics. The last set of charts is the 
actual frequency distributions of all responses. Finally, an alphabetized list of all responses to 
the "other" category is included and provides another view of the important issues facing the 
people who manage information technology in higher education during the 1990s. 
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Security Issues 



Frequency Distributions 
For All Institutions 
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Aging Systems 
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Other Responses and Their Rank (Sorted Alphabetically) 

Rank Response 

4 Access to workstations for students & employees 

1 Admin vs. Academic computing (% spent on each) 

1 Align IS/IT with Business 

2 Alliances with other agencies & Institutions 
4 Burnout 

1 Business Process Re-engineering 

1 Campus backbone 

2 Campus Control 

1 Co-operative Acquisition of Systems with other Institutions. 

2 Computing in the Curriculum 
7 CWIS 

6 Data Administration 

4 Dealing with quick development of Technology 

5 Determining the Effective Size of Computing Hardware 

6 Development Environment 
12 Development Backlog 

4 Disaster Planning 

6 Distance Learning 

12 Distributed Environment 
EDI 

3 Educating Customers/Users to think globally about systems 
1 Efforts of Legislation/ Lack of Funding 

1 End User Computing 
9 End User Support 

2 Executive Info. Systems 

4 Exploiting technology in the Classroom 

3 Faculty Development & Training 

1 Gaining full support of faculty & staff 

2 Implement Software Platform 

3 Increasing productivity; Keeping up with Technology changes. 
12 Industry Shakeout and Rational Business Relationship 

1 Information Access 

2 Information Access 

5 Integration 

3 Integration into Educational Program 

3 Integration of Images into Database 

12 Involving Sr. Administration in Futures 

1 IT in the classroom 

6 LAN/Wan & integrated comm. 

1 Modify college procedures to maximize benefits of technology 

1 Multimedia 

4 Multimedia 

12 Organizational Structures 
4 Outsourcing 
12 Pay 

1 PC-Unix-Mainframe Connectivity & Databases 

12 Print/Doc. Distribution 

12 Processor and Operating Systems Platform 

4 Productivity of Analysts/Programmers 

1 2 Programmer/ Analyst Productivity Tools 

4<;o 
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Other Responses and Their Rank (Continued) 
Rank Response 



5 Proliferation of Micros 

1 Seeking Base Budget Commitment 

8 Software Updates 

7 Staff Reorganization to meet user needs 

5 Support for Multimedia 

12 Support Personnel 

12 Technology use in Learning (Multimedia) 

3 Telecommunications 

1 The intersections of teaching and learning with information 
5 TQM 

4 Use of Technology in Teaching 

2 User Based Systems 
1 User Training 

3 viruses 
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I. Introduction 

Collecting and processing data about and providing information on all facets of the institution 
is what administrative computing is all about. From its meager beginnings in the financial area, in 
most institutions, administrative computing has expanded steadily. Today it would be very 
difficult, if not impossible, for an institution to function long without these automated systems. In 
the main, the information produced from these systems has been distributed periodically to the 
appropriate consumer in paper or microfiche form. With the availability of inexpensive terminal 
equipment and telecommunication networks, most institutions have purchased or developed on-line 
access systems that provide enquiry and/or update capabilities to these administrative systems. 
Until recently, this capability was reserved exclusively for the administrative offices in almost all 
institutions. While providing the on-line access for themselves, the administrative offices were 
very reluctant to offer the same service to the academic offices. They were even more concerned 
about offering the service to faculty, staff, and students. 

In a research study conducted in 1990-91 (Biddle, 1992), I queried faculty around the world 
about their perceived on-line requirements for several administrative system s(referred throughout 
this report as the faculty needs study). As an extension of that study, I have now queried the 
administrative offices responsible for these systems to see if they are now offering or plan to offer 
on-line access to faculty. The appendix contains a summary table of the responses to the various 
questions. 

II. The Study 

In an attempt to discover how the institutions are responding to the requests for faculty access 
to the on-line administrative systems, I conducted a second national survey. The study was 
performed in a manner similar to the original 1991 faculty needs study. An 18 item questionnaire 
(see appendix) was transmitted electronically to several discussion groups on BITNET and 
INTERNET 

In place of the Likert scale used in the faculty needs study, respondents were requested to 
indicate the availability of the items as currently available, available within 6 months, available in 6 
to 12 months, available in 1 to 2 years, thinking about doing it but not yet scheduled, and will not 
provide access on-line. Early on in the replies, one institution indicated they needed a category for 
'"had not considered the possibility". This category was immediately added to the questionnaire for 
all future transmittals. No attempt was made to contact those already submitting responses to ask 
for an adjustment given this new category. Another category that appeared was *don V understand 
what you mean". The questionnaire was not revised to include this category. All data were tallied 
as they were received unless the individual requested specific clarification. In those cases, a 
message explaining what was meant by the category was returned to the requester and their data 
were not recorded until a new response was received. 
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While most of the items in the questionnaire were analogous to those in the faculty needs 
study, several item's were new. These new items were taken from the list of "extra" items provided 
by the respondents to the faculty needs study. It is for this reason that no statistical correlations 
are being made between the two surveys. 

Those institutions that do provide on-line access to administrative systems data do so in 
several different manners. One procedure is to incorporate the access into the campus-wide 
information system (CWIS). The most definitive information on CWIS can be found in an article 
by Judy Hallman (1992). Jones (1992) reports on an implementation of CWIS at Appalachian 
State University. Another procedure is to simply expand the number of users by permitting access 
on an individual basis. The process is to grant access to the systems to anyone who has received 
the appropriate security clearances. 

III. Analysis of the Data 

Even though a category of "had not considered the possibility'" was added to the 
questionnaire, it was not included in the final analysis. Data are reported as percentages of 
responses to a given item. Where the data provided interesting results, I have recalculated the 
percentages to include the " had not considered" category. I have, clearly indicated when this 
occurs. If not specifically identified otherwise, all calculations do not include this category. The 
data \a sre further reduced by combining all categories where the item was either already available 
or scheduled for production. This then created on- hree categories. The charts that use all five 
categories will use the following identifying format, a = currrently available, b = in 6 months, c = 
in 12 months, d = in 24 months, e= have yet to schedule, and f = will not provide. The charts 
that use the combined format will use: 1 = available or scheduled, 2 = not scheduled, and 3 = will 
not provide. The bias of electronic mail responses only was not considered a factor in this study. 
This study is concerned only with responses from CUMREC-L, CWIS-L, CAUSEASM, and 
ADVISE-L subscriber institutions. 

A. Student Related Items (Figure 1) 

Student progress toward a degree is called by various names. Some institutions call it degree 
audit while others call it academic progress (Singer, 1992). McCauley and King (1991) report as 
many as nine vendors are currently marketing software for progress toward a degree. It would 
appear that more institutions, providing this service, use the DARS software created by Jack 
Southard and his group at Miami University of Ohio 1 than any of the other packages. Another 
institution that has developed its own system and currently licenses it to others is Brigham Young 
University. A discussion of the development of this system can be found in Kramer and 
Rasband's (1992) article. 

53% of the respondents indicated they have this system installed and available for faculty use. 
6% indicated it would be ready in 6 months and 6% more indicated it would be ready for use 
within a year. In all, 74% either have the system available or plan to have it available. 13% are 
considering the possibility of providing the service but, as yet, have not set a target installation 
date. 13% stated they had no intention of providing access to an on-line degree audit system for 
faculty access. It was impossible to determine, from the responses, whether this meant they had 
no intention of installing a degree audit system or if they were not going to provide faculty access 
to it. 

In the faculty needs study \ electronic class rosters were an item that 85% of the faculty stated 
they needed. 70% of the institutions responding have heard this request and currently provide this 

1 For information about DARS (Degree Audit Reporting System) , contact Jack Southard, Miami University of 
Ohio at his BITNET address: southard@miamiu. 
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service to their faculty. 18% are considering the possibility but do not have it on their 
implementation schedule. 6% will not provide the service to faculty and an additional 6% plan to 
have it ready for use within 24 months. 

At the other end of the term, offering the ability to file final grades electronically from a faculty 
workstation is a possibility at only 1 1% of the responding institutions. An additional 4% should 
have the service ready by now. 15% plan to have electronic grade filing available to their faculty 
within 2 years while 30% stated they are considering the possibility of offering the service but as 
yet have not scheduled it for production. 41% have no plans to ever offer this service. 
Interestingly, when the "had not considered" is included 21 % stated they had not considered the 
possibility yet. 

Comparing electronic rosters and electronic grade filing, it is not surprising to note that all but 
one of the institutions offering electronic grade reporting also offer electronic class rosters. Of 
interest is the fact that 22% of those already providing electronic class rosters will also have 
electronic grade filing available in 2 years. Another 26% are considering the possibility of 
providing the service. A very interesting response was received from the 6% which stated they 
had no intention of providing on-line class rosters. 100% of them responded that they were 
thinking about offering electronic grade filing even though they had no intention of providing class 
rosters. 

Providing the ability to inquire into the file of a student during the advising process was a 
relatively high priority among faculty with advising responsibilities. 41% of the institutions 
responding are currently providing this service to their faculty. 7% more will have it ready within a 
year and 19% in 2 years. 

A more sophisticated system would provide the ability to change the demographic data in a 
student record. Such access obviously requires additional security and one might anticipate that 
fewer institutions would offer this service. That is in fact the case. Only 9% offer the ability to 
change student demographic data from a faculty workstation. 58% stated they had no intention of 
ever permitting changes to student demographic data from a faculty workstation. 9% indicated 
they possibly would allow this to happen in the future and 4% have it scheduled for completion. 




Degree Audit Class lists File grades Advisee info Change info 

Figure 1 

B. Financial Related Items (Figure 2) 

Researchers with control over financial accounts have been asking for on-line ability to inquire 
into the status of the accounts, to initiate purchase requisitions and purchase orders, and to query 
the progress of purchase requisitions(PR) and purchase orders(PO). 54% of the responding 
institutions reported they provide inquiry capabilities for individual financial account holders. 
Rivkin and Hurley (1992) report that such a system has been succesfully implemented at Princeton 



University. An additional 8% plan to have the service available within 2 years. Walsh and 
Holland (1992) provide insightful information concerning their current progress in implementing a 
very sophisticated user friendly system for Indiana University. 21% have the issue under 
consideration but not scheduled for production. 27% currently provide the ability to initiate a 
purchase requisition and 57% of this group also permit creation of a purchase order at the 
workstation. Interestingly enough of those that permit the initiation of both a purchase requisition 
and a purchase order only about three quarters will also let the individual monitor the progress of 
them through the system. Of the institutions that do permit on-line creation of a requisition, the 
same percentage permit monitoring the progress through the system, however the two groups are 
not composed ol the same institutions. 

When looking at the set of institutions that do not currently offer on-line access to the creation 
of a PR, 4% have it scheduled for completion in 6 months and 15% more in 2 years. Fewer plan 
to offer on-line PO generation. Offering query capability to the progress of either a PR or a PO 
seems to be more pervasive in the next 2 years as 2 1 % of those not already offering this service 
plan to have it ready within that time. 

27% of all institutions reporting are considering the option of on-line PR initiation outside the 
Purchasing Department. Of these 71% are also considering the possibility of permitting the 
initiating the PO. 25% of the institutions have the progress of PR/PO issue under consideration. 
19% have no intention of providing on-line PR generation while 7% will not establish PR/PO 
inquiry. 42% stated they would not permit PO generation on-line outside of the Purchasing 
Department. 
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C. Grade hooks (Figure 3) 



In addition to providing on-line class rosters, many faculty were interested in the possibility of 
an electronic grade book. While this was not spelled out in detail, most faculty wanted to be able 
to record grades on tests, quizzes, and homework and to have the system calculate at least 
percentages and possibly apply weights to various categories of recorded work. Some even 
wanted the system to create the letter grade from the data. 32% of the institutions already provide 
electronic grade books for the faculty. 10% will have it ready in 2 years and 4 1 % have no intention 
of offering the service. Factoring in the "had not considered ", the largest percentage (35%) have 
not considered the option. 

One possibility here is to provide downloading of the class lists to the workstation and then 
providing the faculty with workstation software for the grade book. In my own situation, 
downloading of the class lists to my workstation is all I require (we are currently testing this 
concept). I would transfer the file to my Excel spreadsheet grade book where I have already 
created the weighting factors for each area (quizzes, homework, tests). I currently produce a 
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running grade for the class and a graph of the grade distribution. The final grades and the graph 
are printed and placed on display outside my office door almost as soon as the final tests are 
graded. 




Figure 3 



D. Personnel Related Items (Figure 4) 

Permitting a person inquiry access into their personnel records has been adjudicated by the 
courts on several occasions. While the courts have not stated the access must be on-line, they have 
opened up almost all items in the personnel file for inspection by the individual. Permitting a 
person to look at their own personnel records on-line was something the faculty had an interest in 
having as well as the possibility of changing the demographic information. 

Of those responding to this item in the questionnaire, 28% currently permit their employees to 
view their file on-line. Of the institutions that currently provide on-line access, 14% also allow on- 
line changes to the file, 57% had not considered the possibility of providing this service and the 
remaining 29% stated they had no intention of adding this capability. 

4% of the institutions will add viewing of the files in 6 months, 12% stated they were 
thinking about the possibility and the remaining 48% will not offer the service. 76% of all 
institutions have no intention of ever permitting faculty to update their files on-line but 12% are 
currently looking at the prospects of offering the service. Again, when ''had not considered is 
factored in, a large percentage (26%) had not considered this service. 
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Figure 4 



ERIC 



457 



- 503 - 



E. Other On-line Systems (Figures 5 and 6) 



Several areas of general interest to faculty were expressed as "extra" items in the faculty 
needs study. I selected 6 of the most often requested items to be included in this study. After 
looking at the results of this survey, I have had difficulty rationalizing why on-line access to the 
central library generated ssuch a high percentage response in the faculty needs study since 92% 
already have on-line library services available. 4% will have the library connected to the 
institution's network within a year. Only one institution indicated it has no intention of installing an 
on-line library service for its faculty. 

In the area of general campus information, 43% reported they provide a campus news digest, 
9% will have one ready in 6 months and 1 3% within two years. Less than 10% indicated they had 
no interest in offering a campus news digests on-line. The remaining 26% are considering the 
possibilities of putting up a news digest. Over half currently have an events calender available. 
17% are working on a system and will have it in production mode within 2 years. The remainder 
of the institutions are either seriously considering the possibility of installing an events calendar or 
have not given it any consideration. 




Library News Digest Events Calendar 



Figure 5 

75% reported they had an on-line campus phone directory. An additional 4% are completing 
the system and will have it active within a year. 17% do not believe it is necessary. 

The on-campus stores (supplies) catalog is an item that is most generally found to be out of 
date. It is also relatively expensive to continuously publish revisions as items are added or deleted 
and as prices fluctuate. Usually one copy is sent to each department. Experience has shown that 
the department copy sometimes becomes misplaced or is in use by someone else when it is needed. 
Additionally, the copy is only available in the department office when that office is open. This 
could be 9:30am - 4:45pm Monday - Friday. Many people, researchers in particular, work odd 
hours and require access to the supplies information at times when the office is closed. For those 
individuals, access to an on-line supplies (campus stores) catalog is a time and effort saver. 

In response to this need only 35% of the institutions have installed an on-line stores catalog. 
26% appear to understand the need but as yet have not placed the system on the workload list. 
The remaining 39% appear, by their response, to believe there is no need for this system. At 
present, no one is working on the installation of a system, they either have it installed, are 
considering doing so, or will not install one. 

The final question on the survey had to do with electronic access to the schedule of classes 
from a faculty workstation. Having the ability to look at the schedule of classes was important to 
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faculty. No reason was given for this need but it is surmised that much of it came from faculty 
with advising responsibilities. It has been my experience that a paper schedule is easier to use 
while discussing a schedule with a student than having only 22-24 lines of an on-line schedule 
available at a time. However, if the status of each section (open/closed) is also included in the on- 
line system, then the system becomes more valuable especially during the late enrollment period. 

In any case, 50% of the respondents are offering an on-line schedule. 3% will have one 
available within 12 months and 10% within 2 years. 20% have no intention of putting the schedule 
of classes on-line while a similar percentage (17%) have been discussing the possibility of adding 
this system to their work list. 




12 3 12 3 12 3 

Phone Directory Stores Catalog Class Schedule 



Figure 6 
IV. Summary 

One of the surprising results of this study was the number of institutions that reported they 
had not given formal consideration to the possibility of offering many of the on-line systems that 
were listed in the questionnaire. The percentages ran as high as 35% for the electronic grade book 
to 3% for transmittal of class lists to an instructor's workstation. 

Of the institutions that had given consideration to a particular system, no institution reported 
that an events calendar would never be offered on-line and only one institution was never going to 
offer on-line access to the library system. 

University officials appear to be listening to the request from faculty and researchers for 
access to the on-line administrative systems. Since the survey of faculty needs was initiated in 
1990, many institutions appear to have reconsidered their policy of excluding faculty from access 
to many of the administrative systems. This is very vividly depicted in the figures that follow. 

In th~ student related systems, the category that was listed most frequently was "currently 
available" except for filing grades and updating demographic information. Figure 7 graphically 
shows these relationships even after the data have been aggregated. 
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Figure 7 



It is surmised that the lack of sufficient security and possibly a continuing, but unfounded, 
fear that the integrity of the data files would be broached by offering on-line up load of grades and 
on-line modification of demographic data are the reasons these two items show low current 
availability. It is the author's belief that many of the institutions which stated on-line demographic 
data updates would never be permitted are fearful of corruption of the data by the faculty. Some of 
the reporting institutions not only permit faculty to update these data but go so far as to permit the 
student to change the data. 

Figure 8 shows the comparative results of the responses to the financial related questions. As 
with the student systems, the "currently available" category was selected most often from among 
the institutions where thought had been given to the systems. 



It is understandable that the initiation of a purchase order from a remote location by a person 
not in the purchasing department might meet with some resistance in many institutions. The act of 
initiating a purchase order may require the creation of a bidding process or may require sole source 
of the items from a preselected vendor. Faculty may not be aware of these facts and could cause 
embarrassment for the institution if the purchase order was issued incorrectly. This could be as 
severe as legal action by one or more vendors if contractual or statutory agreements were 



Now ~\ 
6 mo "\ 

12 mo ^ 
24 mo " 
not sched 




Figure 8 
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violated.(Rivkin and Hurley, 1992) On the other hand, the on-line initiation of a purchase order 
does not preclude its monitoring and editing by any number of parties prior to its release to the 
vendor. Institutions might find cost savings in time and personnel if the initiation of the purchase 
order were permitted from a remote location given that electronic signature approvals were required 
at appropriate stages of the process. 

Some financial systems are constructed so that the purchase order is a natural outcome of the 
purchase requisition and is automatically generated from the purchase requisition information. In 
these instances there would never be a need to offer on-line purchase orders.(Rivkin and Hurley, 
1992) 

Institutions do not show the same progress toward providing on-line access or update to their 
personnel systems as they do to their student systems. When the access and update responses to 
the student and personnel systems are compared graphically, this difference is quite apparent, 
(figure 9). 




Figure 9 
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V. Conclusion 

Institutions responding to this questionnaire appear, for the most part to be providing, getting 
ready to, or planning to offer on-line access for faculty to most of the systems listed. More 
consideration needs to be given to such items as electronic filing of grades and the ability to query 
and update personnel records by the faculty member. 

Additional studies in this area might: 

1 . explore the reasons why some institutions do not plan to offer on-line access to faculty to 
certain systems. 

2. evaluate the same questionnaire with institutions not subscribing to the discussion groups 
this questionnaire was distributed to. 

3. conduct an in depth analysis of a selected few institutions that are the leaders in providing 
on-line access to their systems as to why they decided to provide the service. 
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Appendices 

Appendix 1 The questionnaire 

The following is a list of potential items that could be placed on-line for access by academic faculty 
where the proper "need to know" exists and data item security is in place. Please respond by 
placing the requested letter after the item and returning your response directly to me to keep the 
discussion group traffic down. If you are not the person to respond, please forward this note to 
some one who can respond. My address is jcbiddOl @ ulkyvm (BITNET) or 
jcbiddOl @ ulkyvm.louisville.edu (INTERNET). 

A = installed and available 

I = installing within the next 6 months 

P = planning to install in 6 - 12 months 

F = planning to install in 1 - 2 years 

T = thinking about installing but no plan yet 

N = will not install 

1 . Students* progress toward a degree information 

2. Class rosters 

3. Electronic filing of course grades 

4 . Assigned advisee information 

5 . Ability to change student demographic information 

6 . Ability to query financial accounts of research grants 

7 . Ability to initiate a purchase request on-line 

8 . Ability to initiate a purchase order on-line 

9 . Ability to query the progress of a purchase request7order 

10. Electronic grade book 

1 1 . Access to library information system from faculty office 

1 2. Campus new digest 

1 3. Campus events calendar 

14. Campus phone directo.7 

15. Campus stores catalog 

16. Query and update master schedule of classes 

1 7. Ability to query personnel file 

1 8. Ability to update demographic data elements in personnel file 

Thank you for you time in completing this survey. The results will be most helpful and useful to 
you colleagues. 

Cordially, 

Dr. John C. Biddle, Associate Professor 

Information Science & DP 

School of Business 

University of Louisville 

Louisville, KY, 40292 

(502)588-6121 




Appendix 2 Chart of percentages without "hcui not considered*. 



Degree progress 
Class rosters 
Filing Grades 
Advisee info 

Change student demo info 

Query FRS 

Start PR 

Start PO 

Query PR/PO 

Grade book 

Library system 

News digest 

Events calander 

Phone directory 

Stores catalog 

Query sched of Classes 

Query personnel file 

Update personnel demo info 











r\v en i cixJ i \s/ 






1NOW 


f\ JYIA 


1 9 tnn 


94 mo 

i»*T 1 J l\J 


Scheduled 


Not scheduled 


No 


J -J /o 


\J /o 


6% 

u /o 


9% 


74% 


13% 


13% 


/u /o 


u /o 


u /o 


\j /o 


76% 


18% 


6% 


I 1 /O 


4.% 


0% 

u /o 




10% 


30% 


41% 


*t i /o 


0% 

U /O 


7% 


17/0 


67% 


15% 


19% 


1 7 /O 


u /o 


*t /o 


0% 




19% 


58% 


/o 


U/o 


t /o 


4% 




21% 


18% 


97% 


/o 


1 £ /o 


19% 


S5% 


27% 


19% 


1 S% 

1 J /o 


H- /O 


0 /o 


o /o 


3S% 


23% 


42% 


J / /o 


7% 

/ /o 


1 1 /o 


7% 

/ /o 


/o 


30% 


7% 


J L. /O 


0% 




i% 


42% 


18% 


41% 


92% 


0% 


4% 


0% 


96% 


0% 


4% 


43% 


9% 


9% 


4% 


65% 


26% 


9% 


59% 


7% 


7% 


3% 


76% 


24% 


0% 


75% 


7% 


7% 


4% 


93% 


0% 


7% 


35% 


0% 


0% 


0% 


35% 


26% 


39% 


50% 


0% 


3% 


10% 


63% 


17% 


20% 


28% 


8% 


0% 


4% 


40% 


12% 


48% 


8% 


4% 


0% 


0% 


12% 


12% 


76% 



ERIC 



-511 - 



CUMREC 

BAYLO* ' . .fCk 0 * 
UNIVIIwTY ^•WJ 




San Antonio 





INFORMATION 
TECHNOLOGY: 

The Revolution 
Continues 



ALTERNATE PAPER 



Confessions of a Project Manager 



Jim K Gorham 

Baylor University 



38th Annual 

College and University 

Computer Users Conference 

Hosted by Baylor University 

in San Antonio 

May 9-12, 1993 




r t n b 



— 513 — 



CONFESSIONS OF A PROJECT MANAGER 

Jim K. Gorham 

Director of Accounting Services 
Baylor University 
P O Box 97041 
Waco, Texas 76798-7041 
JIM_GORHAM@ADMINAFFAIRS.BAYLOR.EDU 



Fall 1986 arena registration was in full swing, on about the fourth out of five 
scheduled days Russell Gym was full of frustrated students who had waited until 
the last minute to be admitted, advised, and registered; yes, the lines were long! 
Most students had not yet submitted financial aid applications, much less thought 
about how they would pay their registration bills. Classes were scarcer than hen s 
teeth and I had had it up to here with problems. Student bills were still being 
calculated manually and were posted to ledger cards. Baylor did however have an 
on-line class registration system that did a good job of keeping up with schedules, 
but would only interface with other systems once a semester in a batch operation. 

Yes I was in charge. No one hesitated to ask me any question, any number 
of times Very politely they would be answered ... one by one. During the height 
of the excitement, none other than the Vice President for Information Systems came 
up to me, put his hand on my shoulder and said, "I would like for you to be the ^ 
project manager for the implementation of our new student information system. A 
thousand thoughts raced through my head: ( How could I refuse? I couldnt turn 
down a Vice Presidential request! I could delegate this wonderful registration job 
to mv able-bodied assistant. Brother, did the VP know when to catch me when I 
was most vulnerable! When do I start? Now? No, better wait and get registration 
wrapped up.) 

That was how I became the Project Manager for the implementation of 
Baylor's new Student Information System. In the last six years, after the successful 
completion of SIS, I have been Project Manager for two additional software 
systems, a large financial system and a loan management system. Needless to 
say, I am very thankful for the experiences and desire to share a few ideas I have 
learned along the way. 

PROJECT MANAGER 

Ideally the position of Project Manager should be full time. If not the Project 
Manaqer should be relieved of as many other responsibilities as possible. No 
implementation can run any faster than the slowest decision or project can be 
completed. The cost of time must be considered when this important decision is 
made How quickly do you want the system to be implemented? Is the old mam- 
frame computer about to go? If you are installing new hardware as well, is the cost 
of annual maintenance or. the old computer more than the cost of allowing the 
Project Manager to be full time? 
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PROJECT TEAM 



Like the Project Manager, the Project Team should be comprised of 
competent personnel dedicated to the successful implementation of the system and 
be representative of every vital area affected by the software. Representatives of 
the computer center are as vital as any other area and must be included. Who else 
can say you can't get a computer to do a double back flip when it is obvious to the 
user that is what is needed? 

Each Team Member should: 

1 . Have the trust and support of his/her supervisors 

2. Be knowledgeable of his/her respective areas 

3. Be able to think independently 

4. Be willing to work hard and willing to give extra hours 

5. Be able to communicate well 

6. Be bold enough to defend one's own area's interests 

7. Be open to compromise with others 

8. Know when to do either 6 or 7 above. 

At the first meeting the Project Team should establish a weekly meeting day 
and time which must have priority over all other meetings. Meeting location may 
change to accommodate members as necessary. A change of scenery may trigger 
a "better idea." 



During the meeting: 

Have an Agenda. An unorganized meeting can have too many 

tangents, although you should leave room for 
miscellaneous items at the end. 



° Keep Minutes. 



° Be under Authority 



° Make Assignments 



Someone (consider the Project Manager) should 
record minutes of every meeting to document 
decisions and to be able to report on the progress or 
the lack there of to a responsible party. 

The Project Team must report to a person in 
authority who will keep them accountable for their 
actions and who can run interference when 
necessary. 

Each member will be responsible for decisions in 
his/her own area but should be assigned additional 
duties as necessary that do not fall into anyone's 
specific area. There will be plenty of these to go 
around! 



Maintain a Calendar Early in the project, specific goals and objectives 

should be established with realistic dates of 
accomplishment. Create a calendar showing each 
goal and how it relates to the others. Visual 
schedules help to emphasize the importance of 
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each step by showing that the failure to meet one 
goal will have a major impact on the entire project. 
(Use an erasable marker since reality seldom 
mimics plans .) 

Prepare Project List Most software packages come with a conversion or 

installation list of projects. This is a great beginning, 
but schools often want additional enhancements. 
Prepare a prioritized list of each enhancement, 
report, interface or special programing request that 
includes a brief description and estimated time to 
complete. A comments/status column will keep 
everyone informed. Once established, the priority 
and comments will constantly change. Also, keep 
all completed projects on the report. The Project 
Team will gain a real sense of accomplishment 
when reviewing the list after several months. Don't 
view the list as an insurmountable task, but 
recognize it as a challenge or even as Job Security! 

Ask "Why?" Every school has rules for accomplishing each task. 

When questioned, the answer many times is, "That's 
the way we have always done it." or "It has served 
us for 20 years, there is no need to change now."-- 
Don't buy it! For each and every decision there 
should be a rational reason. No, the above two 
quotes are not rational! What will happen if it is 
done another way, or why even keep doing it? What 
is the end result? Is there some intermediate 
benefit? Question everything like a five year old. Be 
able to defend decisions with the determination of a 
high school senior and the wisdom of a grandfather. 

Make the Decision Someone has to decide everything. Many 

questions are simple and easy to answer. Don't be 
afraid to make decisions that are really 
inconsequential. Confession time! When we 
converted marital status values from our old system 
to the Student Information System, we only 
converted (M)arried and (S)ingle. (D)ivorced and 
(W)idowed were converted to single. Team 
Members agreed that the reason a person is single 
is not relevant to the university. The decision was 
made by the Project Team without anyone else's 
approval. Remember: "It is always easier to get 
forgiveness than permission." 

Be Gracious Have an open attitude of compromise. Try to 

visualize the needs of the other offices. There is 
always a solution. Some of the best suggestions 
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came from Team Members who were not involved 
directly with a conflict and could step back and 
suggest an easy solution. 

INTERNAL PROCEDURES 

Each Team Member should direct the review of all internal procedures within 
his/her respective area. The Team Member should keep a critical eye for the 
reason of each procedure and how it will be accomplished in the new system. This 
review should include the flow of information through each area. Again, ask why 
do we do it by steps 1 , 2, 3, ... ? Would it be more efficient to do 1 , 3, 5, 2, 6 and 
skip 4? Can the same information be obtained elsewhere or does anyone still 
need this report? New internal procedures should be written with a good 
understanding of the new system as well as input from co-workers. Internal 
procedures should be reviewed on a regular basis. 

INTERFACES 

One major consideration will be interfaces. What other systems will feed 
information into the new system or what other system will be expecting information 
from the new system? Who will write the interfaces? Can it be handled in house or 
will you need to contract it out to a software vendor? Who will coordinate what 
information is needed to be transferred between systems? 

REPORTS 

Make a listing of all reports produced by the current system. If done in 
January, the annual federal reports will be listed. If done in July, you will wish you 
had done the listing in January. It doesn't matter when it is done, a group of reports 
will not be remembered. However, every effort should be made to prepare the 
most complete list possible. Now see what reports the new system will prepare for 
you. How many reports will the new system prepare? How important is each 
report to the university? From this research prepare the listing of reports that must 
be written, converted or modified. 

TEST, TRAINING, AND PRODUCTION 

How much space will the computer have for files? Hopefully there will be 
enough room to have three systems -- Test, Training, and Production. The Test 
system will allow experimenting and testing new programs, modifications, fixes and 
"great ideas" without compromising the integrity of Production's "real" data. This 
will be the programmer's playground. Training will mimic production except for the 
data. The Training system will provide a place for all training of the Project team 
first and later the staff. Training is where mistakes can be made and no one will get 
upset. Students of the system can relax knowing "it doesn't really matter." 
Production is where it really matters. This is the live data. This is the "real" world! 
Production must balance and be reconciled. Production is LIFE! 

Some schools will not have the luxury of having three independent systems. 
As a minimum, a modified Test version and a full Production system are required. 
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Fight for as much as you can, but realize this is another area of possible 
compromise. 



Use the Test system to try as many scenarios as possible when testing the 
initial system, any modifications or "fixes". Think of every scenario possible, 
because if you don't, someone else will with the production data and require the 
programmer's midnight oil to burn once again! 

SYSTEM TRAINING 

There will be several rounds of training. The first training will normally be by 
the software vendor. Usually the training is presented by module or specialty area. 
It is most important that the entire Project Team be included in every training 
session. Most systems are so interrelated that a comprehensive understanding of 
the system is the only way the Project Team will be able to intelligently discuss any 
conflict. In addition to Project Team members, primary users should be included in 
the specific training seminars. This will provide a good forum for input from other 
sources. Additional questions may be raised and future problems avoided. 

After the formal training by the software vendor, training materials should be 
prepared for use by all end-users. Provided materials can often be modified to 
reflect university procedures. By developing your own materials, generalized 
assumptions can be removed and specific examples inserted. End users should 
be trained in a timely manner without rushing or skimming any important topics. 
Materials with plenty of illustrations and references can provide the same comfort 
as a teddy bear. 

SECURITY 

Security is a major issue at many institutions. The Project Team should be 
aware of the abilities and limitations of the delivered security system. Knowledge 
of the exact mechanics is not as important as what the system can and cannot do. 
Each member should review the security needs within his/her own area and 
recommend how it can best be served. 

Another big question is how much access will one area obtain in another 
area's domain? Some higher authority will ultimately have to decide who can see 
what in many cases. The need to know must be answered appropriately. 

REPORT WRITER 

Many systems have a form of report writer. If available, one person in each 
area should become the resident expert. He/She will be responsible for the reports 
for that area. Having the ability to perform such tasks locally, not only frees the 
programmer's time, but allows the user access to the information desired, not 
necessarily requested -- too often this is not the same thing. More information can 
be extrapolated faster and in a more meaningful format. A good report writer can 
pay l or itself in a very few months with the savings in not having to rely on a 
programmer's time (salary). The alternative is to wait weeks for your turn to have a 
report prepared by the computer center staff. 
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CONCLUSION 



When does a Project Manager stop being the project manager? In reality no 
one can pinpoint an exact time. Once the software is in production and the system 
is running there will still be several unresolved items. The computer system will be 
in a constant state of evolution. The Project Manager's new responsibilities will 
take precedence over former obligations. However, in the minds of the users, a 
good Project Manager will always be the resident expert on the "system". Phone 
calls will continue long after the Project Manager has gone on to "bigger and 
better" things. 

The Project Manager must gently wean the users of calling first with every 
question and have them to begin researching the answers themselves. For the 
benefit of the institution, a quasi-project team should remain organized to resolve 
conflicts that will continue to raise their ugly heads. Most software packages are 
so integrated that a decision in one area will most likely have an effect on another 
area and it must be resolved to the benefit of all parties concerned. The need for 
coordination will never cease as long as we rely on integrated software. Questions 
will continue for ever and ever. Amen. 
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General Information 

The University of Alberta is one of Canada's largest universities. 
Student annual enrolment star, at close to 30,000, academic staff number 
almost 2,200, and full time support staff total more than 3,000. Parking 
Services is a division in the department of Physical Plant. It currently 
provides services for 13 lots and 5 parkades, with approximately 17,000 
permits and 350 on the waiting list. The number of tickets processed 
annually is well over 75,000. 

There has been much interest expressed in distributed computing in 
the information systems industry. Many questions have been received on 
ticketing hand-held units and mainframe interfaces with parking systems, 
through CUMREC correspondence. This paper shares our experiences in 
implementing a Parking application with many functions and interfaces in 
a new and diversified distributed environment. 

Project Background 

The old parking system was first developed in 1974 using IMS data 
base technology and upgraded in 1978. Data entry was via a video 370 
batch processing system, and on-line inquiry capabilities were restricted. 
The functions of Parking Services have expanded extensively in the last 
fifteen years, as new parking lots have been added along with new card 
access systems. The number of transactions has increased significantly due 
to increased numbers of students, parking violators, permit variations, zone 
preference changes, and increased interfacing with other University 
systems. 
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The objective of the new system was to be an integrated application, 
capable of interfacing with other systems such as Comptroller's financial 
system, payroll system, student record system, and hand-held ticketing 
units. It had to be a multi-user system so that the parking operations 
network could be provided with the most up-to-date parking information. 
It would also provide essential information for the future developments of 
the University facility management and financial systems. 

Evaluation of Re-development Alternatives 

When evaluating the redevelopment alternatives, it was difficult to 
reach a conclusive decision. Like many information systems analysts and 
management today, we were facing the dilemma of choosing to develop in 
the micro computer environment vs the mainframe environment. The 
options were: 

1 . Purchase vendor software with minimum modifications 

2. Upgrade the existing IMS Parking System 

3. Undertake new system development on the mainframe 
using IMS 

4. Develop a new micro system jointly with central 
computing, Physical Plant and Parking Services as a 
central computing supported product 

5. Develop a new micro system in-house by Physical 
Plant 

The central computing department, Computing and Network Services 
(CNS), was going through extensive organization changes and a strategic 
planning process at the same time. The emerging technological 
infrastructure of distributing computing was a mandate to be considered for 
all system development. One component of the CNS Mission Statement 
was that "CNS must create the necessary computer and human 
communication framework to provide an integrated distributed computing 
environment which ensures interoperability and appropriate exploitation of 
hardware, software, and computing knowledge." 1 

After deliberation and an extensive decision analysis process, the 



1 "Networking Computers and People on Campus and Beyond," 
Strategic Plan for Computing and Network Services, February 1992, p. 6. 



selection committee decided that going the route of Option 4 (Develop a 
new micro system as a central computing supported product,) to be in line 
with the University's future computing direction. 

Project Development 

The project was developed through the normal system development 
life cycle - Objectives, Business and Design Specifications, and 
Construction. The construction period was from January 1992 to 
November 1992 (10 month period). The development team was 
responsible for the complete system development, hardware purchases, 
software and new release upgrade, LAN set-up and network 
administration. The team consisted of one to four system analysts 
(depending on the development period) from CNS, one analyst from 
Physical Plant, and the staff from Parking Services. Management from the 
three areas participated in monthly status reviews. 

The operating environment that was chosen before the project 
development and later reaffirmed as the best development environment at 
the time, was OS/2 with Extended Services (Data Base Manager, Query 
Manager), Ethernet network with OS/2 Lan Server. The development tools 
used were Microfocus COBOL Workbench and Graphic User Interface 
(GUI) Dialog for screen development. 

The proposed local area network (LAN) configuration was one server 
with five workstations. A server and three workstations were initially tested 
and set up in CNS before moving to Parking. Currently the LAN has 
expanded to six workstations and two printers. 

New System Functions 

The new Parking Data Base is a relational data base, consisting of 17 
main tables 2 , 25 look up tables and three system generated association 
tables. The automated system interfaces built into the system are very 



2 The main tables are: Customer, Active Payroll and Student Name, 
Licence, Licence Customer Reference, Lot Allocation, Lot Inventory, 
Number Control, Payment, Permit, Permit Payment, Permit Rate, Shift 
Totals, Transaction Logging, Violation, Violation Payment, Violation Rate, 
and Waiting List. 
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extensive. File transfers upload to the mainframe from micro and download 
from micro to hand-held units and vice versa, Due to the mainframe IMS 
data base limitation and the university wide distributed environment not yet 
achieved, most of the data transfer is done via 3270 emulation. The 
automated interfaces have improved the administrative process significantly. 
The built-in interfaces include: 

Payroll deductions (permit and ticket payments, one-time and 
recurring) TO payroll 

Student encumbrances/disencumbrances TO student 
records 

Licence number TO Provincial Motor Vehicle Branch 
(MVB) for addresses 

Financial transactions TO Physical Plant Billing System 
Hot lists TO hand-held ticket writers (Clancy units) 
Name and Address FROM payroll and student records 
for effective permit and ticket notices mailing 
Name and Address FROM MVB for up-to-date 
registered owner information and name matching 

- Tickets FROM hand-held units 

The outstanding features provided with the micro operating 
environment allow great improvement to the on-line/batch development, 
more than initially anticipated, such as: 

Powerful screen presentation with windowing, pull- 
down menu, push button, and multi-tasking capabilities 
(see sample screens in Appendix A) 
Easy to develop and maintain screen/report layout 
Ease of user control and maintenance of the on-line 
menu and look up table to reduce future system 
maintenance 

Flexible searching and display by index retrieval, 
powerful customer searching (by name, payroll ID, 
student ID, permit, licence, violations) to determine 
permit eligibility 

- Improved batch runs with on-line parameter editing 

Efficient name matching and connecting disconnected 
licences 

Variable length and horizontal scrolling of remark 
fields 
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Dynamic file name opening and closing for manageable 
data logging and creation of small print files 
Powerful and flexible user generated reports from 
OS/2 Extended Services Query Manager. The 
simplified Query Manager update capability has 
eliminated the need of data base restore from backup 
due to job submission errors 



The permit application process allows more flexibility for processing 
applications from staff, students, visitors and special guests. Its features 
enable Parking Services to: 

Accommodate annual, seasonal and casual permit 
applications for staff, students and visitors 
Provide management of waiting list, zone preference 
and priority 

Specify renewal processes selectively by customer type 
Provide an effective and multi-functions permit rate 
table 

Incorporate a number of optional steps such as 
customer summary, group licence query, 
add/renew/update permit, add/update/refund payment 
into the Permit Application process. 



The parking violation processes received the most significant 
improvements in record keeping, printing notices and payment processes. 
New features include: 

Facilitate the upload of hot list from the Parking 
System to hand-held units and download of violation 
from hand-held units to the Parking system (this was 
the greatest time saving in data entry and corrections) 
Transfer effectively and timely student encumbrances/ 
disencumbrances to the student record system, 
complete with current owed amount 
Automate accumulation of violation amount and totals 
at customer and licence levels 

Provide aging of violations, tow list and encumbrance 
withhold control in table by customer type 
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Use multiple payment receipts with a future interface 
to cash registers 

Automate appeals and improve appeal process results, 
keeping all original data recorded for tracking 
Use enhanced messages on violation notices, including 
appeal acknowledgment and decisions 

Parking lot management is a new feature to efficiently manage limited 
parking space and provide information on available space readily and 
effectively for annual and casual permit parking. 

Able to schedule or reserve space for special visitors, 
maintenance, etc. 

Manage in and out temporary permits so that space can 
be used efficiently 

Plan to interface with kiosks (field attendants) in the 
future for up-to-date space availability information and 
message sending 

The Financial Management is automated with selective financial 
transactions to the Physical Plant billing system (University departments and 
General Ledger). Future development will address the complete financial 
functions to include cash drawer interface, credit cards, ledger, etc. 

Major Difficulties 

There were difficulties in implementing this project; some were 
expected, and some just evolved. It was an adventure using the new tools 
and the LAN operating environment. Some of the major difficulties were: 

Formal training of application development in OS/2 
was not available and there was no knowledgeable 
resource person to contact. The project team basically 
resolved most of the technical problems in-house 
through self-study and experimentation 
The software new release upgrades and fixes were very 
time consuming 

There were more system design changes than in 
traditional system development due to the newly 
discovered flexibility and capabilities of the data base 
engine, operating environment, and tools 



The procedures and standards had to be developed and 
modified along the way 

The development team was responsible for all 
hardware and software problems, such as hardware 
acquisition hold-up, the backup tape drive was not 
compatible with OS/2 2.0, etc. The exact cause of 
many problems was difficult to identify 
Network set up and administration took away valuable 
development time 

The distributed system required training and 
establishing easy to do steps in system back up, 
network administration, large volume printing, lengthy 
file transfer uploading and downloading procedures 
The data conversion process from IMS to the new data 
base structure was time consuming and difficult. The 
process was speeded up by changing from the utility 
load to inserting tables with a COBOL program 
Long running programs required many reviews and 
modifications to improve performance 
Interfacing data with other applications provided a few 
surprises, such as change in field format and length, 
and different coding structure 

What We Have Learned From Our Experiences 

In spite of the difficulties, this project was completed to the 
satisfaction of the users. From the technology development point of view, 
it was a big stepping stone to our next level of technology. Choosing 
Parking as our pilot distributed system was a good choice. It was an 
independent system yet there were many interfaces that we had to address. 
We have learned a great deal in relational data base technology, setting up 
the LAN, working with micro tools and the shift from mainframe program 
development to the GUI screen flexibility. The adventure of developing the 
distributed system with the user does fulfil a key strategic issue of CNS: "to 
provide a network infrastructure and the technical expertise and leadership 
to help users make effective use of network computing." 3 We were 
fortunate that we had a dedicated development team with some micro 



3 "Networking Computers and People on Campus and Beyond, " 
Strategic Plan foi Computing and Network Services, February 1992, p, 10 
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experience. "No one is perfect, but a team can," and indeed the entire 
team had to work very closely together. A lot of innovation and creative 
thought was needed in researching new ways to improve processes, as well 
as resolving problems. 

The entire project team was able to stay focused on quality and system 
performance which were vital in developing a well structured system. 
Some of their knowledge of successful mainframe systems v; as transferred 
to micro developmerft, such as parameter flexibility, table driven concept, 
and batch jobs test simulation, to provide a basis to maintain quality and 
standards. 

Setting up standards early, such as the menu set up, the naming 
conventions, and program maintenance procedures, was very important. 
Many difficult decisions had to be made with insufficient knowledge. We 
were also prepared to modify and improve those procedures as our 
knowledge and expertise increased. 

Parking and Physical Plant were committed to the project and they 
provided us with the utmost trust and cooperation. Parking Services had 
to adjust to extensive changes from a data entry batch system to a powerful 
on-line data management system. Their office was renovated to 
accommodate the new equipment. The staff had little system expertise and 
they had to rely on Physical Plant and CNS. Parking Services management 
decided to implement the Clancy hand-held units six months earlier than the 
system production date. That was one of the wisest decisions to reduce the 
stress of adjustments to two major changes at once. 

The biggest lesson we have learned is that software development 
methodology is changing rapidly. The traditional structured approach is no 
longer effective for micro application development because of the 
tremendous flexibility available. It is important to solidly build the 
architecture and framework of the data base structure and the overall 
design. The final working screens and batch processing were constantly 
upgraded and changed for better performance. However, we did not 
compromise our primary objectives and requirements. Although we had to 
throw away some early stage unit design and code, we believe that in the 
end we gained productivity as well as performance, because of the 
persistence in improving each process. 



Conclusion 



We feel that we have successfully implemented our first distributed 
micro application and are proud of the final product. We have learned 
important lessons on the complete micro application development process 
including LAN set up, server and workstations management, file transfers, 
distributed program updates, data backup and job submission. The 
knowledge gained has been valuable for Physical Plant, Parking Services 
and CNS, from a department point of view, as well as from a University 
point of view. 

The users are pleased with the flexibility of maintaining their own 
system and generating their own reports easily. The parking staff now 
manage and maintain a Parking management system instead of being the 
data entry and verification clerks they were a few months ago. They still 
need to access the mainframe for file transfers, occasional encumbrances, 
and running a utility to create a licence file on cartridge. The dependence 
on the mainframe has reduced greatly and the system is cost effective for 
Parking Services. 

We learned that migration to new technology is costly in time and 
resources but the experiences were invaluable. We did have fun along the 
road and hope that this experience will help us in our next technology 
upgrade to the University wide distributed environment. 

On-line Demo 

Now we would like to do a 15 minute demo of the parking system and 
show you some of the powerful screen presentation as well as the flexibility 
of the Query Manager for generating user reports. 



ERIC 



4S2 

— 531 — 



r 



Appendix A 






-I 



' ft: 
ly: 



Select and. PwT 




Manager . 



£rou1ia(<a 



: : :: : : : :: : x : :|p^Mij : : : : 



fiS£W*tftaw Quttcy Manager-fa* Ctiaowsr SfjwtfVAftf 




4b.l 

— 532 — 



- Main On-L 

Customer Summary 
Licence Summary 
Group Licence Query 
Violation Payment 
Violation Update 
Violation Add 

Permit / Wait List /Guest Park 

Active Name Query 

Name Match 

Guest Booking Query 



- Batch File Transfers 

CARS Encumbrances 
PLUS Payroll Deductions 
JOBS Transactions 
Licences to MVB 

- Batch Updates 

Permit Renewal Select & Print 
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Customer Summary 



[-Customer Id- Namc 



1 i 



0121745 MACINTYRE FRANK 



Src 



Type Dept Number Remarks 

El W-IqqmTI [ZIZZZH 



Payroll 
Id 



Status 
Exclude 



Id 



□ 
□ 



rStudcnt 
Id 



I 



Status 



•J r O/S Violation^ 
ill Quantity [ 6 



!!Amt 



30.00 



Address - 



i Print Ind 



Jjj-Withhold- 



Type |S | jj Quantity Indicator [? 

Upd Dt |iaflI"fJI2"04 



Last 



11 Dt 



1987-11-02 



Tow Away - 
Indicator 



IT 



Dt 1987-11-021 



Display 

@ Address 

Permits/ 
Wait List 

© Licence/ 
Lie. Ref. 
© Violations 
Q Payments 



Address 



1 153 MACLWAN DRIVE 



[122 8 



! EDMONTON, ALBERTA 



] |T6H jMj 
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Search AtffanR Hc(p 



-Province 4 Licence No. 



IABUD4U 



Source 



Customer 

f T7 TTTTTTT 7TTTT TTTTJ 

: : : : :;:| 



(TviiinnviuiTriTj 

■illli! 



Fleet Ind. 

□ 



MVB Information 
Name 




Ser Number Code Date IS.DS Owed App Dec 



04 450751 
04 455501 
04 529663 
04 543711 
04 502491 



17 


1991 


-05- 


14 


. A 


20 


00 


31 


1991 


-05- 


23 


. A 


30 


00 


04 


1991 


-09- 


10 


. A 


5 


00 


04 


1991 


-10- 


02 


. A 


5 


00 


31 


1991 


-11- 


06 


. A 


30 


00 



A1 D1 



Vehicle Unit No. 

I i 



O/S Violations 
Quantity 
Amt. 



95.00 



rTow-Away- 
! Indicator 



Ol 



i Pate imzwmtW 
i * 

Display 



Iress 
© Customer 
©Licence Ret 
® Violations 



4S6 




— 53£ 



Pay Permit 



r-Current Payment 

! m m m m* m 

i 



rUnit 1 


rMax Amount 


| MO 


! 540.00 
i 


® Payment 
Q Deposit 
01 Replace 


-Amount Remaining- 

! .oo 
i 


■ — ■ — i 



Calculated Payment 

Surcharge -> .00 

Months 12 x 45.00 = 540.00 
Weeks 0 x 1 3.00 = .00 
Days 0 x 4.00 = .00 



|i^feiitcj;;| Calculated Arnt: 540.00 



Payment Amount: | §00 



Invoice/Account U: i 



Payment Method: [_ 



m 



Cash Reg. # JJODS WO): 



Auto-Select: ®Yes 
(Upload) ©No 



Start Date: |1993-n4-01 



End Date: 1994-03-31 
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Violation/Notices Select and Print 



ODD 



Siting 




Duefv Man aw 



::giii*$:'M'iliiii(!iiefc 



r 



Processing Options - 



Q Process All Violations 



General Message Code 



(leave blank if no message) 



Warning and Error Messages Report 

Print Missing Address Errors for Ctj$1omt>r<{ 

j [£# Print Missing Address f;rrors for SlandAlontt Licences 



-Update Options 

! £3 Pun RvawX Violations & Tow/Withhold Indicator* 



i 
i 
i 



H Update Data Ba«« 



Process 



1 



re cord i 



TTtTTTTTTTTT 



'■§§11! 



lill 



22?2P(tfi Cartel: P&king • Maih V(oi-s*ion PaymwiJ 
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